Date: Mon, 31 May 2010 04:44:07 -0600 From: Scott Long <scottl@samsco.org> To: Ivan Voras <ivoras@FreeBSD.org> Cc: freebsd-current@FreeBSD.org Subject: Re: SUJ and "mount" reporting Message-ID: <9EA890DC-CDCF-4E12-BB0E-063153400AB6@samsco.org> In-Reply-To: <htvuap$f3j$1@dough.gmane.org> References: <alpine.BSF.2.00.1005171616390.1398@desktop> <htutrv$cu$1@dough.gmane.org> <20100531002417.R96912@maildrop.int.zabbadoz.net> <htvuap$f3j$1@dough.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >>=20 >>> 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? >>>=20 >>> (running CURRENT from a few hours ago, kernel&world synced) >>=20 >> 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 >=20 > Yes, this looks like it... >=20 >> Using tunefs, etc. for now would be better. >=20 > 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. >=20 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. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9EA890DC-CDCF-4E12-BB0E-063153400AB6>