Date: Wed, 14 Jan 2004 23:33:16 +0100 (CET) From: Harti Brandt <brandt@fokus.fraunhofer.de> To: Robert Watson <rwatson@freebsd.org> Cc: current@freebsd.org Subject: Re: simplifying linux_emul_convpath() Message-ID: <20040114233149.A15693@beagle.fokus.fraunhofer.de> In-Reply-To: <Pine.NEB.3.96L.1040114164938.49872I-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1040114164938.49872I-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@fokus.fraunhofer.de, harti@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040114233149.A15693>