Re: tunefs.8 oddity



Julian Elischer wrote:
Stefan Esser wrote:
Maxim Konovalov wrote:
On Fri, 20 Jul 2007, 23:21+0800, Xin LI wrote:
Any chance that we resolve the bug instead of documenting it? :-)

Personally, I have no energy/time for that. It was documented for
ages, it is still documented in other BSDs.

It has long ago been converted to a mount option instead of a
tunefs command in NetBSD. My FreeBSD systems are patched that
way since shortly after soft-updates was committed (long before
it became available in NetBSD, IIRC); I have not checked whether
they used the (very simple) patches I had posted at that time.

Controlling soft-updates during mount has many advantages (not
only if you decide to enable it on a root file-system that had
been created without it) and no disadvantages.


As the person who added this originally on behalf of Kirk,
I think the time for this has probably come.
I think even Kirk has said this might now make sense but I'd check
with him first.

I had asked him and he replied that the mount option was better.
But when I discussed this in a FreeBSD list, there was strong
opposition and it was claimed, that sysinstall took care of it
in such a way, that the users would not miss the mount option.

I had strong arguments in favour of the mount option, but since
there were different opinions that were strongly voiced, I just
gave up and maintained the changes locally to this day.

The arguments (of both sides) can be found in the mail archives.

I think this change should have been made long before 7.0 (it
could have been in 5.0 without problems). But I guess that ZFS
will attract many previous UFS2/soft-updates users (I have
converted most of my systems to ZFS with quite satisfactory
results and could now live without soft-updates) and that the
relevance of soft-updates will shrink for that reason. So if
it is not changed in 7.0, I won't keep my local patches, since
there will be no UFS file system on my systems (I'm using a
ZFS root partition and have only a UFS boot partition).

Regards, STefan
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"