[arch-releng] btrfs support in aif
C Anthony Risinger
anthony at extof.me
Tue Dec 7 23:05:08 CET 2010
On Tue, Dec 7, 2010 at 3:15 PM, Dieter Plaetinck <dieter at plaetinck.be> wrote:
> On Tue, 7 Dec 2010 14:34:02 -0600
> C Anthony Risinger <anthony at extof.me> wrote:
>> i have some other responses to this message, but this for now...
>> On Tue, Dec 7, 2010 at 11:23 AM, Dieter Plaetinck
>> <dieter at plaetinck.be> wrote:
>> > This is why softraid hasn't been implemented yet, nor btrfs.
>> > Also, I'm not very familiar with either one (although I am pretty
>> > interested in btrfs).
>> > I would need to know the most common/recommended use cases, and
>> > figure out the best way to implement them.
>> > Or maybe just provide a few predefined wizards for specific setups
>> > (but there are so many possibilities this would be unfeasible, I
>> > think)
>> > Or I need to take a different approach (see a bit above)
>> what if we created some kind of udev/blkid/etc. approach? ie. we
>> write some custom udev rules to manage a special directory/update
>> files/touch files/run scripts/etc... as the system changes udev would
>> make sure AIF knows what the actual state is.
> interesting idea. but if aif really wants to know the current state, it
> can just query (fdisk -l, ls /dev/mapper/*, <btrfs command>, etc etc)
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.
>> i'm not super adept in the rules syntax, but i know enough to be
> the syntax is a bit ugly right now, to keep aif code relatively simple.
yeah i know it's a little strange :-), but it makes enough sense, and
is powerful enough to do all the cool things we rely on it for
>> it seems like we could leverage it in some way to take
>> care of all the dirty work... AIF just needs to monitor the <insert
>> here>, and verify against an identical copy it creates during the
>> install. this would also let AIF adapt to any outside changes made my
>> the user with some grace.
>> C Anthony
> let's not create additional problems. if you suggest to make aif "spot"
> changes made by the user, it still needs to be able to work with that,
> so there needs to be a model for it. we can better implement the model
> and dialogs for btrfs support to work, without worrying about the
> "detecting realtime changes" if we don't really need it.
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)
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:
(terrible example :-)
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
More information about the arch-releng