> Shawn Leas:
> 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)
Well, if you wanna do this, then I happily submit!!! Woo hoo!
> The "END"? The "middle"? Kill that bloated abstraction! There need
> not be any concept of disk order. Get that non-scalable thought out
> of your head. Think about what happens over time as you add and
> remove 500-GB RAID boxes. You will run off the end of the address space.
Methinks you misunderstood me. The "removing from the middle" idea was
actually just that. Someone suggested they should be able to shrink the
LV anywhere, and have to FS adapt. An actual loss of blocks, that would
require massive reallocation.
<snip me saying LVs should be "seen" as simple to the fs>
> This is bad. It may be simple, but it is limiting.
> Note that more complicated stuff can be hidden from the admin.
It may be limiting, but many times when you want to change the "layout" of
an LV, you should just mirror it to a different one.
> >>> 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.
I know, see above. People have been saying that ext3 should be like
playdough and dance around your LV shrinking/resizing until it barfs.
I would be suprised if the gain you get from this outweighs the added
complexity for the FS.
> > 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.
Like I said, above, if you wanna do this, I happily submit, and this was
not the crux of my disagrement. The ability to "get" this information
from the LVM is valuable to the FS, no doubt... The trouble is when you
place too loose of restrictions on the LVM regarding the FS... Example,
allow shrinking of an LV if ext3 is on it, and there's "room in the
filesystem". I just think the LVM should wait until your FS isn't
alocating whatever blocks you wanted to remove. I don't think that's
limiting.
-Shawn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu