Date: Wed, 25 Sep 2002 10:16:42 -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: <3D91EF7A.EF4918C@mindspring.com> References: <20020924175642.GB87963@southcross.skynet.org> <200209250958.g8P9wXE10208@flip.jhs.private> <20020925151358.GD16302@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Dan Nelson wrote: > You don't need journaling for undelete capability. When you delete a > file on Netware, the file is simply marked "deleted" but the filename > stays in the directory, and duplicate deleted filenames are allowed. > When true free disk space gets low, deleted files are purged in the > background, oldest first (I believe). There is an API for listing, > salvaging, and manually purging deleted files. I know Netware 3 had > salvage capabilities, and it certainly didn't have a journalling FS :) > > You might be able to misuse the Whiteout file type in FFS to present a > similar user interface. unlink(2) would rename the file to > filename.timestamp and whiteoute it. ls -W, rm -W, and rm would list, > salvage, and purge, respectively. Since S_IFWHT is a filetype, you > would have to only allow file deletion, or encode the original filetype > somewhere else. > > Alternatively, you could add a file flag equivalent to whiteout. > "invisible" or something, and use chflags to salvage. As the author of NXFS (The NetWare for UNIX extended File System) for Novell in 1993/1994, I can say that things are a little more complicated than that, when it comes to undelete. 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. I can pretty much guarantee you that "whiteouts" would not work; they exist as masking objects, for use in stacking FS's that overlay the files in an underlying VFS in a stack: they depend on iterated directory searches for unioned namespaces -- as opposed to consecutived searches, when whiteouts are not an allowed option. 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 the structure of on disk hard links must change, in order to permit recovery of the removed directory entry that you want to purge (frankly, it doesn't make a lot of sense to purge old "deleted" hard links that still have directory entry links referencing them...). This would be an interesting problem to solve; it is similar to the "versioning FS" problem... which has the same need for kernel globbing for correct implementation (the purge in that case is manual or based on an ACL limit on the number of versions of a file which will be maintained, which makes it much easier). -- 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?3D91EF7A.EF4918C>