lkml.org 
[lkml]   [1997]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Volume management on Linux with the ext2fs.
    Date
    > 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

    Alan


    \
     
     \ /
      Last update: 2005-03-22 13:39    [W:0.019 / U:0.508 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site