[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: VFS Semantics and "find"
From: |
James Youngman |
Subject: |
Re: VFS Semantics and "find" |
Date: |
Tue, 14 Jul 2009 10:36:25 +0100 |
On Mon, Jul 13, 2009 at 5:43 PM, John R.
Graham<address@hidden> 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.