Re: SUJ and "mount" reporting

On Monday 31 May 2010 6:44:07 am Scott Long wrote:
> On May 31, 2010, at 3:08 AM, Ivan Voras wrote:
> > On 05/31/10 02:25, Bjoern A. Zeeb wrote:
> >> On Mon, 31 May 2010, Ivan Voras wrote:
> >> 
> >>> Shouldn't SU+J be visible in the output of "mount" somehow? I've just
> >>> enabled it on a root file system of a machine and while tunefs and
> >>> dumpfs report both soft-updates and SUJ are enabled (after reboot),
> >>> the "mount" command only shows "soft-updates". Alternative question:
> >>> how to verify is it active on a live file system?
> >>> 
> >>> (running CURRENT from a few hours ago, kernel&world synced)
> >> 
> >> As previously stated - this is a hack to do what I think you are
> >> asking for:
> >> http://people.freebsd.org/~bz/20100309-03-mount.diff
> > 
> > Yes, this looks like it...
> > 
> >> Using tunefs, etc. for now would be better.
> > 
> > I did use tunefs, as I've said, but I'm concerned what would happen (if
> > it can - stale kernel?) if the superblock that tunefs reads from the
> > disk and the kernel state are different.
> > 
> 
> MNT_* flags need to be deprecated, and the attributes passed in both 
directions as key-value pairs.  I don't know if anyone else has thought about 
this and what it means for backwards compatibility.

My understanding of nmount() is that that is what it does now.  However, not 
everything is fully updated for nmount().  struct nfsargs is still passed in 
as a blob value with the key "nfsargs" for example.  Presumably SUJ could be 
reported the same way SU is done now.

-- 
John Baldwin