[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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]