Date: Wed, 25 Sep 2002 14:35:09 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Dan Nelson <dnelson@allantgroup.com> Cc: Julian Stacey <jhs@berklix.com>, Paolo Pisati <p.pisati@oltrelinux.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: Hey, is there space for a newbie? =) Message-ID: <3D922C0D.5BF146F4@mindspring.com> References: <20020924175642.GB87963@southcross.skynet.org> <200209250958.g8P9wXE10208@flip.jhs.private> <20020925151358.GD16302@dan.emsphone.com> <3D91EF7A.EF4918C@mindspring.com> <20020925182626.GG16302@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Dan Nelson wrote: > > The NetWare undelete functionality, in particular, the ability to > > delete multiple files of the same name, required that globbing > > take place in the kernel, and that the "deleted" files be marked > > not only in the inode, but in the directory space as well. The > > ability to support hard links is particularly problematic, as is > > the ability to recover a particular version of the file. > > That's why I included a rename operation as part of unlink(2). :) That > way there's no globbing problem. I knew duplicated filenames would > cause problems, and timestamping the filenames makes it easy for the > user to pick which one they want to restore. It's up to the > implementor to decide whether undelete(2) automatically renames the > file back to the original, I guess. The main issue is that you can't put the timestamp into the name; it can't be a namespace incursion. And you can't not include it in the namespace on lookup, or you end up getting the wrong file, or stopping with a false positive on lookups. Therefore, a timestamp (assuming that's considered adequate), must be considered both on iteration, and on other interfaces that deal with names. > NSS's implementation is really neat, btw. Deleted files in deleted > directories stay where they are, instead of moving to DELETED.SAV. All > that's missing is a "salvage everything deleted between T1 and T2" > command to allow your to recover from rm -rf's. It's hard to do this... by which I mean computationally expensive. > > The low-space-purge facility is also exhorbitantly expensive, unless > > you can maintain parent pointers for all files, so that you can > > traverse the entire non-free inode list, and make a decision that > > way, and then *delete by inode number*. This basically means that > > Yes; I can't think of an easy way around this. Parents for all files, > or just deleted ones? How did NWFS do it? The way NWFS handles this in the Native NetWare implementation is to not support the concept of hard links. The directory entry is the inode, and the entirety of the directory is cached in RAM (the reason why you need more RAM when you have larger disks in NetWare). The way I handeled this in NXFS is by creating a real on-disk node for hard links, where the data and instance references were seperate, and maintained a forward and reverse linked list of instances, as stored on disk, referenced by inode number. I had to do this so that the FS could be used in UnixWare, Solaris, and AIX as if it were another regular UNIX FS implementation. The net effect of this is that each filesystem object, including the hard links, has its own on disk instance representation. When you add or remove a hard link, you increase/decrease the size of the instance ring for the references. Because it's a ring, you can arbitrarily select an inode to be "the primary inode", and then reference it. A lookup means a reference from the secondary inodes to the primary, unless the primary is already there. If the directory reference to the arbitrary primary is removed, then you have to do some juggling, so that the next instance reference is replaced in the directory entry which references it, and the previous value is removed. The order of operation is to swap the instance refrences, and then delete the directory reference to the (now non-primary) instance. This lets you create a DOW (Delayed Ordered Write -- a technology similer in effect to soft updates) barrier for the operation (in a soft updates world, it would permit you to create a dependency entry), thus guaranteeing FS state will not be indeterminate. It's very easy to sketch, if the verbal description isn't enough. The hard part was supporting a UNIX, DOS 8.3, and Appletalk namespace, simultaneously. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D922C0D.5BF146F4>