[arch-releng] btrfs support in aif

[Dieter Plaetinck]

On Tue, 7 Dec 2010 16:05:08 -0600
C Anthony Risinger <anthony at extof.me> wrote:

> true, but that is synchronous, and dependent on polling and specific
> tools which may or may not have feature parity.  udev would provide
> near complete abstraction to all interested block devices, in a
> unified and predictable way.  we could set traps in AIF, and use udev
> to send signals when devices change.
> 
> AIF would become an event driven framework.

okay, i get you now.  *if* we would want to do this, this seems like an
interesting approach.  although we could also create a "rescan real
system" function which you could trigger from a menu entry, with a
small user inconvenience you could simplify this considerable.
however I still think none of this is needed.

> the whole real time thing was more of a bonus [future] effect of tying
> to udev directly.  i think we could implement the model by looking to
> your examples about LVM, because btrfs is very similar:
> 
> 1) enumerate physical devices (create partitions/etc)
> 2) enumerate devices nodes (LVM:PVs -- btrfs:"devid")
> [devices/partitions] 3) enumerate block pools (LVM:VGs -- btrfs:FS
> itself) [maybe md here even?] 4) enumerate logical volumes (LVM:LVs
> -- btrfs:subvolumes) ....
> 10) Profit!
> 
> simple FS's would have 1-1-1 mappings, whereas the more complex ones
> would be otherwise.  this is why i said make udev build directories,
> and touch/edit files... we dont need a bash data structure, we could
> use the tmpfs itself, something like:
> 
> /devices
> /devices/managed/....
> /devices/managed/target0/....
> /devices/unmanaged/sde3/....
> 
> (terrible example :-)

okay so instead of a text file containing FS structure definitions and
FS properties, you would model the FS structure definition with a
directory tree (and probably still keep FS properties in text files).
this approach isn't better then what we have now. (esp. not when you
consider automated installations, where you prefer specifying your FS
structure definition as plaintext)
also this does not support multiple parents (like a VG over multiple
PV's)
i'm still more in favor of using an optimised plaintext format (like
yaml or whatever) and using a commandline (yaml) program to
query/manipulate the data.

> 
> udev could maintain file indexes or anything else we need.  AIF would
> behave similar to the systemd, in having high level triggers (link PV
> 1,2,3 -- VG 100% -- LV 40/60%) cascade into lower level instructions
> that understand their own dependencies and fulfill the original
> request; decoupling the process a bit.
> 
> AIF then waits for (and expects a particular) outcome back from udev.
> ie. after being signaled by udev, AIF expect <N> nodes to exist under
> "managed", named <label>, with pointers to <UUID>
> 
> just some thoughts, with plenty of holes i'm sure.  it's to hard to
> encode all the various implementation details into AIF; let the apps
> made for these things just do what they do best.  this feels
> interesting to me so ill try to hash out a prototype int the coming
> weeks :-)
> 

the main reason the current model is needed is because aif allows
a user interface that lets the user "build" his FS structure
conceptually, before anything is really done. (i.e. if user says "i
want to encrypt /dev/foo and give it label bar", aif knows it needs to
create a /dev/mapper/bar in the UI so that the user can define something
else (like lvm or a simple FS ) on top of that, and so on.

Your approach can't help here, because it only works after certain FS's
are actually being created.
I don't see which problem your proposal solves.

Dieter