Messages in this thread | | | Date | Thu, 25 Jun 1998 11:40:29 +0100 | From | "Stephen C. Tweedie" <> | Subject | Re: (reiserfs) Re: LVM / Filesystems / High availability |
| |
Hi,
On Thu, 25 Jun 1998 11:38:51 +0200, Florian Lohoff <flo@quit.mediaways.net> said:
>> Because the block device is the right place to do performance-related >> stuff like striping, whereas all the filesystem needs to do is to spread >> out its data over all the available space --- which it does already.
> So the already implemented linear mode is not an block-device issue > more a filesystem one and should be removed ?
The md linear mode _will_ be redundant, yes; however, people will still want compatibility with older kernels, and may want linear concatenation of devices for other reasons (other filesystems and raw device access, perhaps). I'm not advocating removing it, but I am saying that the filesystem is a much more flexible place to do it; it will give the same functionality as md linear, but with several advantages:
You should be able to use it on a root filesystem
Can be extended dynamically at run time
> When i think partitioning via partition table like nearly all OSes have > i find 1050 4MB partition after i used the system 2 years ... great.
You must have a really weird useage pattern, then. :)
> Nobody says we dont need the filesystem to resize. But the filesystem > CANT do it without the block device as otherwise (in case of shrink) > you will not be able to reuse the free space, or (in case of grow) > you will overwrite another partition as this might be at the > end of the existing one. ext2/3 WONT be able to resize without > any block-device communication
It will not be able to shrink once it is down to a single partition. With that one exception, it will be able to grow and shrink (it already _can_ grow) with out bdev intervention.
> How do you describe the new partitions then ? Will you add another > layer above the block-groups called disk-groups or something ..
On disk, they are described simply as a linked list of partitions. The superblock of each partition contains a volume-id field pointing to the next one, and we already have code for other purposes to search out block devices by ext2fs volume id.
>> That's just a property of the historical ext2fs design.
> This is why i mentioned it would be better to drop this concept, > of doing resizing into the ext2.
then...
> You NEED resizing in the filesystem correct. But the filesystem will > not have to deal with non-linear block-adressing (e.g. holes) > and different physical devices as this is done in the LVM.
Does this mean that the solution you are advocating is LVM plus a filesystem other than ext2fs? The block group descriptor problem is a fundamental one which makes any ext2+LVM solution hard. What are you suggesting to work around this?
>> I really don't follow the argument. You seem to be asserting that we >> can solve dynamic filesystem resizing in the block device layer without >> any explicit filesystem support. That is simply not true.
> No ... but i say if you will build this into ext2 we wont have > it for any other filesystem to use. If we have a "toolkit" > in form of the LVM it makes it more easy to implement for > other filesystems like reiser, dt, or lj.
That's right. Build it into an LVM and it still won't be there for other filesystems to use. Doing resizing in the filesystem is sufficiently hard that having LVM interaction or not makes almost no difference to complexity. An LVM will _not_ make it significantly easier to implement in another filesystem, I'm afraid. (Things are different in many LFS designs, of course, where it becomes almost trivially easy to do any form of dynamic data relocation.)
> I like this too ... but i also want different filesystem types to be > able to grow/shrink. Think of having ext2 for my system disk and any > kind of log-structured thing for my news-base.
OK, if you think you'll have a log structured filesystem working and stable any time soon then we'll all be happier hackers. :)
> This is thought in ext2 dimensions. Other filesystem implementation > strategys might be resizeable with another 100 lines of code > whereas ext might need 5000. This is what i say. Its an design > issue which now should be thought over as we have a working > LVM.
Sure. I've no objection to seeing an alternative filesystem which addresses such issues, but saying that this is not a problem because it's ext2-centric ignores the fact that most of the Linux world _is_ ext2-centric and is likely to be that way for a while yet.
> ? Assuming you have a linear block addressing in the filesystem > it makes it very easy to cut of at the end as you dont need to > correct ANY block pointer except to blocks moved to free the > space, but this is problem whereever you have to move blocks.
Plus inodes relocated, of course. And this is exactly my point; doing that relocation plus maintaining the reference counts in a safe manner is hard. It doesn't matter where you are moving the blocks from.
--Stephen
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |