>>>> That data is stored in a daemon-specific way, such as /etc/foo.
>>>> An LVM-aware filesystem directly uses multiple devices, but only
>>>> as instructed by the daemon. Those devices may be any mix of
>>>> PC partitions, RAID devices, and whole disks. Sub-partition space
>>>> allocation can be done by the deamon creating md devices.
>>>
>>> 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)
>>> if it grows, you must explicitely grow the FS, and it will have
>>> grown at the END!!!!!!!. The addition of differing numbers of
>>> extents in the middle of an LV breaks the abstraction and is,
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.
>>> All resources given to anything on the system by the LVM will be
>>> simple, and things will be transparent. It will look like any
>>> other device.
This is bad. It may be simple, but it is limiting.
Note that more complicated stuff can be hidden from the admin.
>>> 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.
>>> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu