On Sun 04 May 2008 at 08:37PM, John Levon wrote:
> I agree that this should work, but zoneadm isn't ready yet:
>
> - it uses stat() not stat64() on the special device
> - for other than hsfs, it insists upon a raw device
(Where is that hsfs special-case code?)
> The former is (presumably) a simple fix. The latter is trickier: we
> don't have a raw device to fsck. Perhaps zoneadm shouldn't be insisting
> on a fsck pass anyway, or maybe this just shouldn't be allowed. What do
> you think?
Sorry-- I may be *totally* confused, but...
Why couldn't one fsck an e.g. ufs image living in a file? fsck
seems to be OK with that at least for UFS.
> > Two final questions: (1) is there any potential interaction with fsck(1m)
> > here? In other words, if the file we're looping back represents an FS
> > which requires an fsck stage, how will that work?
>
> Exactly like it does with lofiadm+mount today (or any direct mount
> invocation): it'll mount without checking.
I guess what I meant was that with lofiadm + mounting today, presumably
I can specify fsck'ing in /etc/vfstab when I place a vfstab entry
there. Maybe no one does that, or even uses vfstab, since the lofi
devices don't persist across reboot.
On the other hand, the man page suggests that one write a script to
persist lofi configurations (blech). I wish lofiadm just supported that
natively.
> > (2) Will the lofi nodes created in this manner be visible in the
> > output of lofiadm(1m)?
>
> Yes. I did toy with an alternative where it won't appear in /devices/,
> but it was not nice implementation-wise, and after some thought felt
> that listing the lofi entries was the right thing to do anyway.
Ok, thanks. You might wish to amend the proposal to specifically state
that.
-dp
--
Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp
