On Mon, Jul 13, 2009 at 5:43 PM, John R. Graham<[email protected]> wrote: > Although it makes sense, I hadn't until recently realized that the VFS layer > imposed the following semantic on mounted filesystems: the filesystem type > of the mount point is made to reflect the filesystem type of the mounted > filesystem. To illustrate the effect, consider the following command > sequence: > > ceres ~ # umount /mnt/usb > ceres ~ # find /mnt/usb -maxdepth 0 -printf "%F %p\n" > rootfs /mnt/usb > ceres ~ # mount /dev/sdb1 /mnt/usb > ceres ~ # find /mnt/usb -maxdepth 0 -printf "%F %p\n" > vfat /mnt/usb > > Note that the reported filesystem type changed from "rootfs" to "vfat" after > the mount. As a result of this perfectly logical behavior, I've tripped over > a subtle issue with my favorite little backup program (flexbackup). It's > hard-coded to not back up filesystems of type "tmpfs" (and others like "proc" > and "devfs"), which is generally a good thing. But since the filesystem type > of the mount point is a reflection of the mounted filesystem type, flexbackup > fails to backup empty directories that are the mount points of those special > filesystems. After a recent RAID subsystem write hole crash and subsequent > restore from tape, I was left with a system that wouldn't boot cleanly > because some unobvious mount points were missing. Now this was simple to > fix: I booted a rescue CD, mounted the root filesystem, and created the mount > points. It took all of three minutes. Still, it would be much better if the > system was ready to boot after a full restore and didn't require manual > tweaking.
I was aware of this property, but hadn't anticipated that effect on your backup system. > flexbackup uses "find" to create the file list to back up and, after studying > the situation, I don't think that "find" has a test that can identify a mount > point's underlying masked filesystem type and, as a result, I can't see an > easy way to get those mount points that mount "special" filesystems on the > list to back up. > > So, two questions: > 1) Am I missing something? Is there a "find" test that will test the > underlying mount point's filesystem type? Not as far as I know. Using -xdev though will ensure that find only examines one filesystem. So if you're using it to make a list of files to back up, you need to run it once for each filesystem you want to back up. The list will include the top-level directory. It seems to me then that the bug could be seen to be in the restore process; the backup for a filesystem contains an entry for its root, it's not in the backup of the filesystem on which it would be mounted. > 2) Would a patch that introduces a new test like that be considered? Or, > perhaps, welcomed? I certainly accept enhancements. But new tests for find would need to be of general usefulness. They need to be useful to people who don't use flexbackup for example. So I would encourage you to discuss your plan/design with the list to make sure your proposed change is going to be useful to more people than just yourself. Thanks, James.
