Date: Mon, 26 Aug 1996 14:17:54 -0600 (MDT) From: Nate Williams <nate@mt.sri.com> To: Joe Greco <jgreco@brasil.moneng.mei.com> Cc: nate@mt.sri.com (Nate Williams), michaelv@mindbender.serv.net, freebsd-isp@freebsd.org Subject: Re: Anyone using ccd (FreeBSD disk striper) for news Message-ID: <199608262017.OAA20405@rocky.mt.sri.com> In-Reply-To: <199608262014.PAA01571@brasil.moneng.mei.com> References: <199608262005.OAA20286@rocky.mt.sri.com> <199608262014.PAA01571@brasil.moneng.mei.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>> Think about it: if you were to unmount your news spool and remount >>> it -ro, nnrpd would continue to work just fine because NOTHING ever >>> looks at the file atime value (which FFS can't/won't modify if you >>> mount -ro)... and if the only reason you are doing an update is to >>> write back the modified atime, what the hell is the value of doing >>> the write? >> >> POSIX compliancy. :) > > Phahff. Screw POSIX compliancy if it's an optional brokenness and it makes > life better. DG has mentioned that it's a real problem for him on wcarchive > in the past, too... and there are some of us who understand the need for > standards compliance but also appreciate that there are times that the rules > can be safely bent. :-) UnionFS would be a *really* good solution in this case. You'd allow someone to have 'read/write' priviledges to the FS (inn, maintainers, etc..), but then re-mount it somewhere else read-only, thus disabling ATIME writes and only allowing read-only FS's. The best of both worlds. Otherwise, I think if you added a flag to the FS to disable ATIME updates for specific filesystems you might get DG to add it. (hint hint! ;) Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608262017.OAA20405>