On Tue, Jun 23, 2009 at 07:46:41PM -0700, John Jason Jordan wrote: > me drag and drop files from the 500GB drive that it is mounted. And I > also assumed that if it is mounted, then any disk writes to the mount > point would go to the 500GB drive. Evidently I am missing a critical > bit of understanding about mount and mount points. > > Before I try again, can someone explain what went wrong?
A mounted drive is just another directory, and the mount point itself without something mounted on it is also just a directory. These are purposely kept very similar to make the software that accesses them simple. But sometimes you can get bitten by the simplification. The easiest way to differentiate a directory that will be used for a mount point, and a mounted partition on that directory, is to make the substructure different, and rely on that. For example, if the mount point directory is /media/foo, then I don't build any subdirectories in it. Meanwhile, if the backup media mounts in /media/foo, then it might have subdirectories ../backup/dirvish/root/ that the backup program is looking for to do its work. When mounted, /media/foo/backup/dirvish/root/ exists. When not mounted, it is absent. The backup program should throw and error message and quit when it can't find the target directory. The problem with this is if the backup program "helpfully" creates all the target subdirectories when it does not find them. It should NEVER EVER do that. If it does, that "feature" should be removed from the source code if necessary, and the author gently flogged. For any program based on rsync, there are switches that prevent this, but that means delving into a vast heap of command line options. BTW, another pathological case is if the mounted backup directory is treated as just another directory to be backed up. This results in exponential growth of the backup directory with copies of itself. Another gentle flogging opportunity. And as always, backup is easy (and obvious), restore is hard. It is important to have a spare drive to restore to, and practice restoring it, before you assume backups mean anything. Yes, a complete backup (and how would you know?) can eventually result in a complete restore, but some restore systems assume more resources and rocket scientist availability than others. It is best to learn about this before an unplanned restore blows your schedule, your deadlines, and your sanity. Keith -- Keith Lofstrom [email protected] Voice (503)-520-1993 KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon" Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
