[opensolaris-summit] Schedule Updates & Moderation and Goals

[Garrett D'Amore]

Tim Foster wrote:
> Hey there,
>
> Garrett D'Amore wrote:
>   
>>>     - all user home dirs on zfs + delegated admin
>>>       
>> It would be really cool if useradd, etc. knew about zfs, for this.
>>     
>
> I agree. This would impact compatibility though, so a -z option to
> useradd would probably be needed.
>
> Then I start to get a bit nervous when thinking about
> filesystem-specific options to commands: what happens when ZFS becomes
> as decrepit as UFS is now[1]?
>   

What about handling this via the ability to configure useradd's "default 
behavior".  In other words, one could imagine a site configuring a 
recipe for useradd to do the thing by default.

>   
>> Yes, yes, yes!! +1 million.
>>
>> I'd love to ditch the use of ufs entirely in favor of zfs, but right now 
>> it is too painful to do this out of the box.
>>     
>
> Wimp :-)
>   

Heh.  I read on ZFS root, and between modifying jumpstart servers, and 
the fact that I frequently upgrade jump start servers, and various 
unclear distinctions about how zfs root interacts with zones and live 
upgrade, I've decided its best to wait until until it is closer to 
production ready.  But that's primarily because I do want to use those 
other features as well.

>   
>>> 	each booting a different root clone, configured slightly
>>>         differently  (or are these just SMF milestones, perhaps we
>>> 	don't need zfs for this at all?)
>>>   
>>>       
>> Yes, I think SMF, or SMF with profiles ala NWAM, is better here.
>>     
>
> That can't take care of booting the system with different driver
> configs though afaik. (okay, unless you boot -a to supply a path to an
> alternative /etc/system)  Yes this idea is a little zany, but I'm
> trying to get people to think of all the ways we could use ZFS, however
> weird!
>   

driver configuration is an area that I'd like to get away from being 
driven by user-driven policy anyway.  Hacking /etc/system or driver.conf 
is painful, and the fact that some sites are consigned to do so today 
IMO represents a bug which we should fix, rather than trying to make it 
easier for folks to do this.

>
>   
>>>     - automatic USB backup hack
>>>   
>>>       
>> Yes.   But lets expand this to SDcard as well.  (What about ZFS on 
>> non-disk media, such as memory cards?)
>>     
>
> Should be okay if the SDcard stuff shows up as removable media. The
> existing stuff I wrote looks for /org/freedesktop/Hal/Manager
> DeviceAdded DBus messages, expecting to see block.device and
> volume.label properties when a volume is inserted.
>
> Regardless, it's probably easy enough to hack it into working properly.
>   

Cool.

> ZFS on USB should be fine, and the existing HAL tools might even do the
> right thing - but I haven't explored this in a while
> (
> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/hal/tools/hal-storage-zpool.c
>  looks like what we're after)
>
> For now, the auto-backup hack expects pcfs as it's the more common
> filesystem on USB disks, but it'd be possible to detect the filesystem
> type and do the right thing (it's a pain having to split backup streams
> to cope with the 4gb pcfs limit)
>   

Heh.  I wonder how the future 32GB SD media deal with that pcfs limit.

>   
>> I'd like to see more flexibility in upgrading zfs pools to increase 
>> redundancy or grow them.  E.g. if I a have a pair of disks in a mirror, 
>> it would be cool to be able to increase the size of the pool by adding 
>> another pair of drives.
>>     
>
> "zpool add <pool> <redundancy options> <disk> ... " works just fine.
>
> Likewise, we can grow pools by gradually replacing existing disks with
> new larger disks. As soon as the smallest disk in the redundancy set is
> replaced, the pool gets bigger. 

I didn't know that!  Neat.

> We can't yet expand raidz sets, but can
> add additional raidzs in a stripe. We can't shrink pools yet either.
>   

Shrink is less interesting IMO.  I think the problem I wanted was raidz 
expansion.  I had a pair of drives (which are now in a mirror), and I 
was thinking at the time, "what if I want to add another disk or two?  
it would be nice if I could configure now so that it would be easy to do 
that later".  I abandoned that idea in favor of a mirror, but I do wish 
it were possible to arrange for raidz to expand later.  (But since 
you've already indicated I can do that with a mirror and with a pair of 
drives, well, I'm much happier now.)

    -- Garrett
> 	cheers,
> 			tim
>
> [1] Yes, I'm thinking a bit long term here :-)
>
>