On Tue, Dec 7, 2010 at 3:15 PM, Dieter Plaetinck <dieter@plaetinck.be> wrote:
On Tue, 7 Dec 2010 14:34:02 -0600 C Anthony Risinger <anthony@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@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 dangerous.
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 nowadays.
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) .... 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 :-) 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 :-) C Anthony