Util-Linux package development
 help / color / mirror / Atom feed
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



      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