On Tuesday 28 October 2003 12:05, David O'Brien wrote:This would also be useful for anyone doing any sort of benchmarking using data sets- I did a code port of LADDIS/SFS to Linux ages ago to do some NFS/SMB fileserver testing, and I can say, quite a LOT of entirely temporary data is generated...
On Mon, Oct 27, 2003 at 01:26:23PM -0800, Wes Peters wrote:
At work we do a lot of dynamic filesystem creation, so we added theNot objecting, but I don't follow how the change is to be used.
ability to specify the 'special file' argument to newfs via the
fstab mount point directory. Please see the attached patch. If
nobody objects, I'll commit this in a couple of days.
Can you post an example?
Sure. Example from /etc/fstab:
/dev/ad0s1d /tmp ufs rw 2 2 /dev/ad0s1f /usr ufs rw 2 2 /dev/ad0s1e /var ufs rw 2 2 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 /dev/da0s1e /spool ufs rw,noauto 0 0
The disk space on /spool is managed by the "application" and isn't
guaranteed to be on-line or even existent when the "system" portion
loads and starts the application. This space is entirely transient
data that doesn't need to be saved across reboots. When the application starts, it checks to see if /spool is clean; if so it
just mounts it, if not it newfs's it and then mounts it. This
space isn't necessarily always "da0s1e" but it is always "/spool"
across different hardware platforms. We prefer to:
newfs /spool
rather than
. {some file full of shell variables describing the hardware} newfs $SPOOL_PARTITION
because the former is slightly more concise. We had a local patch to do this in our 4.x code base, but it seemed a general enough change that others might find it useful as well. I recall ecountering this same problem at DoBox so it appears to be a general problem for disk-based appliances, at least if you want to support differing hardware.
Scott
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
