lkml.org 
[lkml]   [1998]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: (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

\
 
 \ /
  Last update: 2005-03-22 13:43    [from the cache]
©2003-2011 Jasper Spaans