On Fri, 26 Jun 1998, Albert D. Cahalan wrote:
> Shawn Leas:
> > Stephen C. Tweedie:
> >> Shawn Leas:
> >>> No... No no no no no... An LV is a device that will grow/shrink
> >>> transparently to the FS.
>
> Stop. You lose. Transparent to the human admin maybe, but not to
> the filesystem. The filesystem must be aware of the underlying
> devices so that it can do real-time IO bandwidth reservations
> like SGI's XFS for Irix. (think in terms of video streams)
That's for a _specific_ type of application. If you're not interested
in real-time disk I/O, then the LVM abstraction makes the filesystem's
job easy. If you're worried about real-time I/O through a filesystem,
then even when you rule out using LVM as media you've still got some
huge headaches on your hands.
> >>> The LVM will NOT NOT NOT NOT require an FS to get with the program
> >>> and stretch itself because the begin and end points of where an FS
> >>> was have etra blocks in the middle because some bonehead added a
> >>> 3 gig PV where a 2 gig was in the middle.
>
> There is no streching if there is no concept of "middle".
> Think of the LV as a list of disk chunks without any order.
> The disk chunks have ID numbers of course. The filesystem
> can access a block as an ID,offset pair, not by global offset.
Maintaining lists of non-contiguous logical extents is complicated.
It will either be done by the filesystem or the LVM. I would rather
see it in the central LVM code allowing us to leverage existing
filesystems instead of having to write highly specialized fs code to
try to handle LV extents correctly. Again, if you have particular
applications in mind (like RT) you don't want LV's (or anything
"logical", really) coming between your filesystem and the physical
media.
> >>> An LV is a device that will grow/shrink transparently to the FS.
> >>> ... There are rules regarding growing/shrinking that make it
> >>> trivial for an FS to support it.
> >>
> >> I repeat (and it's getting very repetitive...)
> >>
> >> It is *NOT* trivial to extend an ext2fs filesystem, even at the end,
> >> by more than about 256MB. There are fundamental properties about the
> >
> > Sorry, I should have said "relatively". I saw the other mail from ya. I
> > was thinking in terms of ease as opposed to the warped idea of LVM/FS
> > cooperation some poeple were having. ie: FS -> mind-meld with LVM in
> > order to be happy. I did not mean to trivialize the task, again, sorry.
>
> Explain how to do real-time IO bandwidth reservations with a
> filesystem that is unaware of the underlying structure.
Explain how to do it with our current kernel internals, given you know
the performance characteristics of the available physical media.
Adam
-- You crucify all honesty \\Adam D. Bradley artdodge@cs.bu.edu No signs you see do you believe \\Boston University Computer Science And all your words just twist and turn\\ Grad Student and Linux Hacker Reviving just to crash and burn \\ <>< ---------> Why can't you listen as love screams everywhere? <--------
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu