lkml.org 
[lkml]   [1998]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: (reiserfs) Re: LVM / Filesystems / High availability

On Wed, 24 Jun 1998, Stephen C. Tweedie wrote:

[...]
> md already provides the ability to do much of this. The question is
> whether we need to actually resize existing [virtual] block devices:

> ... and fs resizing on Linux will need fs support too. Again, the
> question is, given that the fs needs to add support, do we need resizing
> support at the block device layer TOO? Or is that just extra
> unnecessary complexity? I for one would be quite happy with a scheme in
> which the filesystem could span multiple block devices; that would allow
> shrinking and growing at will, without any complex interaction
> requirements between the filesystem and the block device layers.

i think much of the conceptual complexity here comes from the fact that we
use PC style partitions, and do not have clear distinctions between these
'legacy storage units' and higher level storage concepts. We have 'simple
MSDOS partitions', 'striped partitions', maybe 'LVM managed partitions',
and the concept line gets blurred.

i think the right way to see this is to put away PC style partitioning.
Provide upwards compatibility and some downwards compatibility, but dont
mix these 'PC partitions' into higher level concepts. Once this (painful
...) separation is done, things become easier to manage. Dont try to
handle the 'add this partition to ext3fs' case, it violates the
abstraction barrier. (and thus increases complexity) Yes, this means
something like STREAMS but for persistant storage. Unlike in the
networking case, speed is not that much of an issue, and complexity is our
main enemy, especially as a bug in the networking stack isnt nearly as
critical as bug in a block device driver.

and, persistant data is always a pain as it doesnt go away after reboot,
and i'm wondering wether we should provide a generic framework to do
reliable atomic operations on persistant data (transactions). Otherwise we
would just end up doing our own little imperfect transaction engine,
within fdisk, within ckraid, within JFS/ext3fs/reiserfs. One thing is
sure, the situation (ie. the size of persistant data) gets worse and worse
:)

-- mingo


-
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    [W:0.086 / U:0.648 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site