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 ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/504a7517.1090...@pyro.eu.org
