Re: simplifying linux_emul_convpath()

On Wed, 14 Jan 2004, Robert Watson wrote:

RW>
RW>On Wed, 14 Jan 2004, Harti Brandt wrote:
RW>
RW>> RW>So what ends up happening is what Coda and Arla do: take the 96-bit unique
RW>> RW>identifier (viceid or fid), hash it to a somewhat unique value, and stick
RW>> RW>the result in the vattr returned by VOP_GETATTR().  And sometimes
RW>> RW>applications just get confused. Of course, many of those applications were
RW>> RW>quite capable of getting confused before -- unless you hold a file open,
RW>> RW>you can't prevent its inode number from being reused if the file is
RW>> RW>deleted and a new one created.
RW>>
RW>> The problem is with archivers. Posix guarantees that if the device and
RW>> the inode are equal then its the same file. If they are different its
RW>> another file. If two different files have the same device/inode
RW>> archivers that can store hard links will think that this is a hard link
RW>> and will store only one file. If they are clever they will check the
RW>> nlink is greater 1. But this doesn't help if both files have an nlink >
RW>> 1.
RW>>
RW>> So backups of these larger file systems will likely be hosed.
RW>
RW>This can end up with incorrect operation on a live file system anyway:
RW>nothing says the file with inode 400 can't be deleted, then reused as the
RW>archiver runs, and then count as a false positive...  :-)

You can backup a snapshot. You can also forbid access to the file system
while the backup is running. This is a different issue.

harti
-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
brandt_at_fokus.fraunhofer.de, harti_at_freebsd.org