Re: UFS performance oddities
Hi,
On 07/09/12 21:35, David Given wrote:
> Apparently the eee SSD is pants:
It sounds like an old flash memory module, a bit like CompactFlash or a
cheap USB stick, so it may be just plain slow. And with improper
alignment, the read-erase-write cycle might have taken twice as long.
Now with softupdates, metadata changes might cancel out in-memory and
they get written out a whole block at a time, so write latency is hardly
relevant any more.
> Actually turning it on was an exercise in frustration, as you don't seem
> to be able to use tunefs on a mounted file system and of course this was
> my root partition...
The sort-of-unfinished rescue mode of the installer might be used for
things like this:
http://wiki.debian.org/Debian_GNU/kFreeBSD_FAQ#Q._How_to_use_the_rescue_mode_of_the_installer
A port of Debian Live someday would be very nice though.
> Given what a vast difference it makes (more or less
> the difference between a usable system and an unusable one, on the eee)
> I would certainly suggest enabling it by default. Is there any reason
> *not* to want softupdates?
The drawbacks were explained on this page (last paragraph) :
http://www.freebsd.org/doc/handbook/configtuning-disk.html#SOFT-UPDATES
It sounds like the biggest risk is of 30 to 60 seconds of asynchronous
changes being lost in case of a crash or power failure. It then becomes
the application's problem; making sure to do synchronous I/O when it's
important.
Nowadays I think the situation is better. On Linux the introduction of
ext4fs led to some applications, including dpkg, being patched for a
similar problem. The postfix mailserver also has a debconf choice to
use sync I/O on its mail spool.
I guess GNU/kFreeBSD didn't want to enable softupdates by default at the
time when upstream weren't doing this already, but if they do now as of
the 9.0 release, and PC-BSD have done so for a long time, I suppose we
can now do the same. It seems worthwhile based on your feedback (thanks
for this BTW).
But it's very late in the Wheezy freeze to make a change of this nature
and for it to be able to get proper testing. I don't think it would be
allowed in.
> [...]
>> ZFS should of course be unaffected by the above issue, and be the
>> best-performing choice of filesystem here.
>
> Is ZFS viable on a 32-bit system? The FreeBSD wiki page on it (which,
> being a wiki, is of course out of date, unrepresentative and probably
> wrong) claims that these system is still prone to running out of memory
> and panicking.
Aaah, right, the Eee PC is 32-bit, and is probably low on RAM (meaning
prefetch would get disabled) and doing typical desktop tasks (not
leaving much available RAM for the ARC cache). So ZFS would perform
poorly as a result.
I thought it would have been better at least in terms of write
performance here; its metadata updates are asynchronous because that is
inherently safe, thanks to copy-on-write. And compression can help when
a drive's sustained throughput is also low.
Regards,
--
Steven Chamberlain
steven@pyro.eu.org
Reply to: