[lkml]   [1997]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Volume management on Linux with the ext2fs.
> The really hard case happens when you want to remove a disk from the
> *middle* of a logical volume. This is where things get really painful.
> It can be done with the resizing utility, at least in theory, but the
> resizing utility would need to not only migrate blocks and inodes away
> from the physical disk, but it would also need to renumber all of the
> blocks and inode numbers for all disks *after* the physical disk, and
> update inodes and directories accordingly.

Isnt it an extreme case of "badblock" ?

> filesystem. This would make a really big difference as far as
> performance on busy filesystems and prolonging the life of batteries in
> a laptop computer, since atime updates would rarely get flushed to disk.

Im poking at this at little in a variant form. The PC110 has a 4Mb
battery backed ram disk and a PCMCIA hard disk. What I want to do is
to use the ram disk as a write buffer to the physical media to lower
battery use.

> needs to be done periodically because (a) you want files that are
> written to be actually committed, and (b) disk blocks which are freed
> due to a file deletion or truncation can't be re-used until the commit
> happens.

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).

> As far as hashing or B-tree directory structures, and extent-based
> filesystems, those are things which are possible in the ext2 filesystem
> as well. There is an obvious design question about whether it's simpler
> to build these sorts of things in from scratch, or take an existing
> filesystem and add these features.

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.

> esoteric features such as the log-structured filesystems and generalized
> volume management (beyond just RAID-oriented schemes), you might as well
> start from scratch. However, there's a cost-benefit tradeoff to these

I'd prefer to see volume management as a part of the RAID stuff, even down
to the idea that a disk is a sort of poor RAID0 array. This gives us benefits
we can apply to other file systems too later on


 \ /
  Last update: 2005-03-22 13:39    [W:0.350 / U:2.216 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site