Skip site navigation (1)Skip section navigation (2)
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>