Subject: Re: NetBSD file system on z50
To: None <godwin@orcawerks.com>
From: Todd Whitesel <toddpw@best.com>
List: port-hpcmips
Date: 04/21/2000 03:27:26
> so what we consider long/ big overhead operations in hard discs would
> be minimal in CF right?

This is true, however the CF transfer rates I'm getting from a
SanDisk 192MB are so lousy (180k/sec write, 360k/sec read) that
the instant seek time doesn't buy you much.

FFS as whole is not "optimized for flash" -- if anything, it's optimized
for the performance characteristics of ancient disk drives. However, most
of the techniques that were used are good ones and have stood the test of
time.

The NetBSD implementation of UFS does have some flash-friendly options,
but you have to turn them on because they impact the usual expected
behavior of the filesystem.

The main goal for UFS on flash is to avoid frequent writes. This means:

     1. Reduce or eliminate swap partitions, and try to have enough memory
	to live without them. A 48 meg z50 is actually in pretty good shape,
	and can afford a 20meg ramdisk /tmp, which keeps /tmp off the flash.

     2. Use 'noatime' option on filesystem mounts. Something unix keeps
	track of which I'm pretty sure PC's ignore is the last time you
	accessed the data of a file (the access time, viewed with ls -lu).
	By using 'noatime' you avoid lots of writes that happen during
	normal system operation, when nothing is really being modified.
	Cron jobs like /etc/daily inspect the access time to decide when
	things like core files are "old enough" to purge, so expect that
	to happen more quickly when you use this option.

     3. Use 'nodevmtime' option on filesystem mounts. This stops the
	modification time (last write) from being tracked, but only with
	device files (/dev/console, for example, is theoretically modified
	and its UFS data touched to update the mtime, every time something
	is printed to the screen. Various strategies are used to avoid
	excessive writing and rewriting of this "metadata", however it
	still represents a significant source of write operations during
	"innocent" system use, like if you're just reading man pages.
	Major caveat with 'nodevmtime' is that finger idle times rely on
	the /dev/tty* modification times, so expect that to stop working.

I just heard from someone on current-users who uses noatime/nodevmtime on
all his laptop filesystems and is happy with them.

Todd Whitesel
toddpw @ best.com