From: David Zeuthen <davidz@redhat.com>
To: Karel Zak <kzak@redhat.com>
Cc: util-linux@vger.kernel.org
Subject: Fake block devices (Was Re: `fsck -A` and fs-specific options)
Date: Wed, 13 Jul 2011 11:03:36 -0400 [thread overview]
Message-ID: <1310569417.22917.9.camel@lucifer> (raw)
In-Reply-To: <20110713083214.GA3486@nb.net.home>
Hey,
On Wed, 2011-07-13 at 10:32 +0200, Karel Zak wrote:
> Good point. There is demand for a generic API to assemble block
> devices (dm-crypt, MD, LVM, loopdev, ...). This functionality has
> been requested by desktop guys, dracut, udev and it seems also
> attractive for mount and fsck. I'll probably start to work on this
> task at the end of this year (I hope with DM guys).
>
> The idea is to have a simple library (libblkasm ?) that provide API
> to assemble a block device according to the configuration in
> /etc/fstab and /etc/blkasm.d/. The library should be modular, so
> subsystem specific modules (lvm.so, crypt.so, ...) will be maintained
> externally by subsystem developers. It seems like a good way how to
> keep the functionality up to date and minimize some communication
> problems between people :-)
>
> Note that the original idea is from David Zeuthen
> http://people.freedesktop.org/~david/stc-20101011/stc.conf.html, but
> David's goal was daemon.
FWIW, I've changed my mind about this. Basically, I don't think it's
worth supporting fake block devices (except for dm-luks and maybe loop
devices). Specifically, I will not support it in the next major version
of GNOME Disk Utility (aka Palimpsest) except for showing the "friendly"
dm name (e.g. /dev/mapper/blah) instead of /dev/dm-0. Here's a
work-in-progress screenshot
http://people.freedesktop.org/~david/palimpsest-with-fake-block-devices.png
(Compare to: http://people.freedesktop.org/~david/nautilus-lvm2-b.png )
Anyway, I think it would be better if people instead worked on e.g.
btrfs and making we properly support multi-disk in btrfs... because
btrfs multi-disk is subject to exactly the same problems as you have
when activating RAID or LVM devices (except that you can't do arbitrary
trees - which is a good thing!). For example, there's a policy decision
when to start a device in degraded mode. And, IIRC, the kernel don't
even properly convey what underlying devices a btrfs fs is currently
using (it didn't last time I checked which is ~12 months ago).
David
prev parent reply other threads:[~2011-07-13 15:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-12 2:59 `fsck -A` and fs-specific options Mike Frysinger
2011-07-12 11:02 ` Theodore Tso
2011-07-12 19:18 ` Mike Frysinger
2011-07-13 11:17 ` Theodore Tso
2011-07-13 18:31 ` Mike Frysinger
2011-07-13 8:32 ` Karel Zak
2011-07-13 11:13 ` Theodore Tso
2011-07-13 15:03 ` David Zeuthen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1310569417.22917.9.camel@lucifer \
--to=davidz@redhat.com \
--cc=kzak@redhat.com \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox