Re: Volume management on Linux with the ext2fs.

Matthias Urlichs (
5 May 1997 22:08:25 +0200

"Theodore Y. Ts'o" <tytso@MIT.EDU> writes:
> From: (Alan Cox)
> Date: Wed, 23 Apr 1997 20:35:50 +0100 (BST)
> You are assuming you are logging for the purpose of clean recovery from
> all cases. The laptop case of logging for power management is a simpler
> starting point as you dont care if you have to fsck the disk (and peek
> into the log whats left of it anyway).
> Yes, I'm assuming that someone has a 20 gigabyte news spool that then
> don't want to fsck after a system crash.
That's an important point. I mean, I don't really mind fsck'ing four
4-GByte disks (which can run in parallel), but I sure would be annoyed at
the prospect of fsck'ing one big 16-GB RAID-0 beast (which currently
can't). This is the main reason why I'd rather keep our News spool on
separate partitions instead of raid-0-ing them.

The other reason is of course that there's no tool to combine two small
disks into one big disk. I don't know how difficult that would be to
implement (renumber all the inodes on the second disk and attach its root
to /lost+found?).

> We have the libraries for B trees in the kernel hfs module, and they
> are extremely clean and thus could be readily transported to ext2.
> You mean the Macintosh HFS filesystem? I'll have to take a look at
> those....
HFS, NTFS, whatever. IMHO, B trees are nice. Just take care you stay redundant
enough to actually run fsck on the thing. HFS doesn't score as well as e2fs
here, though still worlds better than FAT. :-/

> It would be interesting to set up disk partitions so they always had the
> md header, so it would be easier to migrate them to using the md driver
> later....

Good idea. Though it'd be easier to tack the header onto the disk's end,
that way attaching it later wouldn't require moving all the blocks up a

I used to be young and stupid, but now I've grown older.
Matthias Urlichs         \  noris network GmbH  /  Xlink-POP Nürnberg 
Schleiermacherstraße 12   \   Linux+Internet   /   EMail:
90491 Nürnberg (Germany)   \    Consulting+Programming+Networking+etc'ing
   PGP: 1024/4F578875   1B 89 E2 1C 43 EA 80 44  15 D2 29 CF C6 C7 E0 DE
       Click <A HREF="">here</A>.    42