Date: Tue, 17 Dec 1996 13:20:40 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jonny@mailhost.coppe.ufrj.br (Joao Carlos Mendes Luis) Cc: mark@grondar.za, toor@dyson.iquest.net, current@freebsd.org Subject: Re: Warning -- Lite/2 merge coming up Message-ID: <199612172020.NAA08756@phaeton.artisoft.com> In-Reply-To: <199612170140.XAA02665@gaia.coppe.ufrj.br> from "Joao Carlos Mendes Luis" at Dec 16, 96 11:40:30 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > What about the other broken FS's, like union and null? > > > > > We have been holding off until the Lite/2 merge. Lite/2 might fix > > some of the problems. > > Sometime ago I was reading the unionfs algorithm on the 4.4 BSD book. > One problem that came to my mind was about the deleted files. > > It says that if one file on the lower layer is deleted, as it shall not > be really deleted, an entry on the upper layer directory is created with > the I-node 1. I believe you are confusing "whiteout" and "delete". The way it *should* behave is as a preemptive negative cache hit, assuming you are using the union FS as a translucent FS... ie: changes to the top level media look like changes to the agregate media even if the agregate media is read-only -- for instance, a CVS update of a CDROM source tree. By preemptive, it means that it returns "not found", and the search is not continued for the unioned media. But if you create the file, then it is deleted, but is pretended to be not found, so that it gets a valid inode allocated for it. For all intents and purposes, then, it's a special entry in a directory seperate from an allocated inode for a directory, which causes the search to exit prematurely until it is removed or replaced. As an overlay FS simply mounted instead of union mounted, the file will not show up; this is because inode 1 is historically reserved as a file entry marker for the bad block list on the drive. Note that this "whiteout" function requires that the FS support two ideas: (1) The directory entry and the inode are seperate things; this means it won't work for MSDOSFS, since in a FAT FS, the drictory entry *is* the on disk inode. (2) The FS type understands the historical reservation of inode 1 (ie: it won't work on ISO9660FS, but who cares, since it's read-only). > And, the final problem: When making a copy from lower to upper layer > (to permit a write access to some file) should this be done by the > kernel ? Is it a good approach ? This could mean a very large > operation, and I don't like to keep the kernel busy for such a long > time. Maybe a daemon implementation (just like portal) should do > this job better. You should use "copy to self". The first lookup for the target for read will get a lower FS entry; the second open for the write will get an upper FS entry by virtue of the open-for-write attribute. This is the one case where "cp foo foo" is meaningful and should not be trapped by the user space tools, but by the underlying FS instead. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612172020.NAA08756>