[oi-dev] Desktop Illumos Still Matters

[Nick Zivkovic]

On Wed, Sep 5, 2012 at 4:18 AM, Jim Klimov <jimklimov at cos.ru> wrote:
> 2012-09-04 22:25, Andrew M. Hettinger пишет:
>
>> was kept in /bin and /sbin that did not depend on anything. This was
>> done to allow you to NFS mount everything else. IIRC the decision was
>> made to go ahead and make them dynamicly linked because noone NFS mounts
>> them anymore anyway, and it meant we had to keep both a simplified and
>> full version of the programs. I think this will encounter many similar
>> issues as that. If we are going back down this road, we could consider
>> just delivering a /bin and /sbin we can use as you propose. It would
>> have the advantage of bringing back this lost (albit rarely used)
>> functionality.
>>
>
> Well, as a little offtopic from desktopness, I have long ago posted an
> illumos RFE 829 to (again) support separatable "/usr" datasets, allowing
> one to compress much of the rootfs among other benefits of hierarchical
> environment (quotas, different storage and stuff).
>
> I've recently redone this on my laptop with no problems, following my
> own logs on wiki and bugtracker; the only substantial blocker was and is
> the "/sbin/sh" being a symlink to "../usr/bin/ksh" or somesuch. System
> fails to boot itself when /usr is separate. Replacing this symlink with
> a hard copy of /usr/bin/bash (as /sbin/sh) does not break the system as
> much as I can see (several machines doing this for several months now)
> and allows to split /usr off into its own compressed dataset.
>
> There were some other nuances discussed in the RFE, like additions to
> the SMF service which mounts minimal root environment, and problems
> with beadm/zfsclone not setting compression attributes on clones,
> but I won't bother you here with those ;)
>
> I just wanted to stress that this is not a feature only useful for
> diskless NFS boots, but also on a PC or a laptop or a VM, especially
> with limited HDD or SSD space and/or IOPS/bandwidth (less reads =
> faster boots).

Agreed. Also, I see that /opt and /usr/$consolidation overlap in terms
of their purpose.

For example we have /usr/X11. According to `man filesystem` /opt is
meant to hold add-on/third-party software.

If that's the case shouldn't X11 be in /opt/X11? Or should the
convention be updated, so that we store the bundles or consolidation
in /usr as is already being done?

If sub-directories of /usr are separate datasets (like /usr/X11 is
rpool/X11), that should make migration easier.

Basically, I'm asking if it is better to have one convention
(everything in /usr/$consolidation) instead of two (some things in
/usr/$consolidation and others in /opt/$consolidation)?

Also, for the SMF nits you ran into, _I think_ we can probably update
the manifests so that SMF doesn't try to start, for example, gdm/X11
until it mounts rpool/X11 onto /usr/X11.

Thanks.

>
> //Jim Klimov
>
>
>
> _______________________________________________
> oi-dev mailing list
> oi-dev at openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev