Date: Sun, 1 Feb 1998 00:49:17 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mikk0022@maroon.tc.umn.edu Cc: Matthew.Alton@anheuser-busch.com, fs@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Filesystem hacking Message-ID: <199802010049.RAA18732@usr06.primenet.com> In-Reply-To: <199801311727.LAA13881@x115-105.reshalls.umn.edu> from "mikk0022@maroon.tc.umn.edu" at Jan 31, 98 11:27:19 am
next in thread | previous in thread | raw e-mail | index | archive | help
> What do you know about LFS for FreeBSD. I haven't used > it, but from what I understand, it was an early implementation > of a "log-structured filesystem" for BSD. Are "log-structured" > and "journaling" synonymous? No, they are not. A log-structured FS logs data; a journalling FS logs data and transactions in a transaction journal. A log structured FS can only roll transactions back to recover from failures. A journalling FS can roll transactions forward. A Journalling FS also allows you to expose a transactioning interface to allow you to group transactions. For example, if you have a relational database consisting of an index file and a records file, you can be guaranteed that a user transaction resulting in both the record file and the index file being modified is atomic, even if the individual operations are not idempotent. This saves the user process from having to process the roll-forward/roll-back themselves, using a two stage commit. It also saves you from reference problems in case of a failure in the middle of the index write for the second stage of the commit. > I know that SGI's XFS is a hybrid, where each filesystem has a log > which stores committed operations on the filesystem. The filesystem > is a fairly normal filesystem from what I understand. The advantage > to the separate log is flexibility -- some installations store > the log on a separate, high speed disk, but most just use an > "internal log" on the same partition as the filesystem. XFS internally seems to look a lot like NTFS internally. That is, it seems to journal. I've only looked at images of small XFS's snapshotted before and after transactions, I haven't really snooped out the structure. > As far as Logical Volume Management, SGI's XLV is a good target > (can you tell what kind of UNIXen I use at work yet? :-). In my > understanding, the system marks each disk with its place in the > volume, so the logical volume can be automagically composed on > boot-up. This is nice, because there is no configuration file to > worry about, and you can move around the disks on the > SCSI chain without affecting the volume. CCD can do this as well. The problem with most logical volume management strategy is that the FS types you could use if it were implemented in BSD can be grown (at the expense of fragmentation), but can't really be shrunk. In both the grow/shrink case, you need a defragmenter that can be run after/before the fact, and can be told to not reuse an area (for the shrink case). This is a pain, since the fragmentation has never really been a problem until you wanted to do this, so nobody has written much code to deal with it. Other than "tar"/"cpio" and using other media to store the image in the interim. 8-(. LFS/JFS/XFS/NTFS can deal with the changing volumes sizes, but only because they already have the concept of a garbage collection process which can be subverted into the role of an FS expander or contracter which can deal with the problem. Logical volume management is one of the reasons IO was unhappy to see LFS go into the attic. 8-(. 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?199802010049.RAA18732>