Re: About soft updates
I've been trying to find out whether to enable soft updates or not, and I have not really seen any reason not to, other than that it is not enabled by default. Pros: * Improved performance * Faster recovery latency after a crash * Can handle a security problem that can occur (AFAIK) in bare FFS (see http://archives.neohapsis.com/archives/openbsd/2006-06/1045.html) Cons: * Less tested than bare FFS * More complex than bare FFS * Disk space is not immediately released (problematic during ugrades) I think the disabled by default solution is fine: if a user knows what he's doing (i.e. knows the pros and cons) he can enable them manually, disabling them on upgrades or other circumstances if required. By default, a well tested and less complex FS, with the default BSD semantics (for example, synchronous directory metadata updates, expected by programs like some MTAs) is provided. The solution adopted by other systems, such as FreeBSD, is to enable them on all non-root partitions. PS: A note in the FAQ saying that all the previous concerns are meaningless if an IDE HD write cache is enabled would be nice.
Re: About soft updates
On Thu, Jul 06, 2006 at 12:35:51PM +0200, Pablo Mar?n Ram?n wrote: I've been trying to find out whether to enable soft updates or not, and I have not really seen any reason not to, other than that it is not enabled by default. Pros: * Improved performance there are known scenarios where it does degrades performance. * Faster recovery latency after a crash this is just not true at all. * Can handle a security problem that can occur (AFAIK) in bare FFS (see http://archives.neohapsis.com/archives/openbsd/2006-06/1045.html) Cons: * Less tested than bare FFS * More complex than bare FFS * Disk space is not immediately released (problematic during ugrades) I think the disabled by default solution is fine: if a user knows what he's doing (i.e. knows the pros and cons) he can enable them manually, disabling them on upgrades or other circumstances if required. By default, a well tested and less complex FS, with the default BSD semantics (for example, synchronous directory metadata updates, expected by programs like some MTAs) is provided. The solution adopted by other systems, such as FreeBSD, is to enable them on all non-root partitions. PS: A note in the FAQ saying that all the previous concerns are meaningless if an IDE HD write cache is enabled would be nice. -- paranoic mickey (my employers have changed but, the name has remained)
Re: About soft updates
Pablo Marmn Ramsn wrote: I've been trying to find out whether to enable soft updates or not, and I have not really seen any reason not to, other than that it is not enabled by default. Pros: * Improved performance * Faster recovery latency after a crash * Can handle a security problem that can occur (AFAIK) in bare FFS (see http://archives.neohapsis.com/archives/openbsd/2006-06/1045.html) Cons: * Less tested than bare FFS * More complex than bare FFS * Disk space is not immediately released (problematic during ugrades) I think the disabled by default solution is fine: if a user knows what he's doing (i.e. knows the pros and cons) he can enable them manually, disabling them on upgrades or other circumstances if required. By default, a well tested and less complex FS, with the default BSD semantics (for example, synchronous directory metadata updates, expected by programs like some MTAs) is provided. The solution adopted by other systems, such as FreeBSD, is to enable them on all non-root partitions. PS: A note in the FAQ saying that all the previous concerns are meaningless if an IDE HD write cache is enabled would be nice. Pablo, Thank you very much for this very helpful answer! /Alexander
Re: About soft updates
* Improved performance there are known scenarios where it does degrades performance. I meant in the general case. * Faster recovery latency after a crash this is just not true at all. Effectively, background fsck isn't implemented yet under OpenBSD and NetBSD (FreeBSD has this feature available since 5.x), but I think it will be soon in OpenBSD: http://kerneltrap.org/node/6 JA: If you still have to run fsck, even with soft updates, why wouldn't a journaling filesystem be welcome? Theo de Raadt: Because, as the paper shows, a journaling filesystem is typically slower, and only really performs well on multiple platters or using an nvram journal. That said, there are changes coming which will make soft update filesystems be capable of background fsck. As it is now, you can mount a soft update filesystem after a crash, and it will work, but the block allocation bitmaps may state that certain blocks are in use, when they are not. So work has to happen to permit background block cleanup. In my message I refered to the general ideas behind softupdates more than to any actual implementation.
Re: About soft updates
On Thu, Jul 06, 2006 at 05:08:56PM +0200, Pablo Mar?n Ram?n wrote: * Improved performance there are known scenarios where it does degrades performance. I meant in the general case. me too Do you refer to systems with low memory (or at least the need to have the kernel not to occupy more memory than a minimum), for example? If not, some example would be really appreciated to get a deeper understanding of the technology. you can start by reading some on the subject... your lame generalised statements on smth you do not understand are not helping anybody... cu -- paranoic mickey (my employers have changed but, the name has remained)
Re: About soft updates
Do you refer to systems with low memory (or at least the need to have the kernel not to occupy more memory than a minimum), for example? If not, some example would be really appreciated to get a deeper understanding of the technology. you can start by reading some on the subject... your lame generalised statements on smth you do not understand are not helping anybody... Well, I read some time ago the basic papers: Soft Updates: a Technique for Eliminating Most Synchronous Writes in the Fast Filesystem (McKusick Ganger) and Metadata Update Performance in File Systems (Ganger Patt). I didn't find any statements about loose of performance (only perhaps the fact that more kernel memory is used to maintain the dependency information, and that hurts in some environments). You know more than me about all this for sure, and I was only requesting politely you to share some of that knowledge. If you don't have the time or don't want to do it, just ignore it. Critizising my lame generalised statements is what really doesn't help anybody in the list who wants to know why aren't softupdates enabled by default (the topic of the thread). E-O-T
About soft updates
Hi, I've been trying to find out whether to enable soft updates or not, and I have not really seen any reason not to, other than that it is not enabled by default. In order not to spread (or consume) FUD, I would like to know if soft updates are considered reliable and in which situations, if any, soft updates are specifically recommended or not recommended. Thanks, Alexander
Re: About soft updates
On Wed, Jul 05, 2006 at 11:19:04PM +0200, Alexander Hall wrote: Hi, I've been trying to find out whether to enable soft updates or not, and I have not really seen any reason not to, other than that it is not enabled by default. In order not to spread (or consume) FUD, I would like to know if soft updates are considered reliable and in which situations, if any, soft updates are specifically recommended or not recommended. Was the answer in FAQ 14.5 insufficient? :)
Re: About soft updates
On 2006/07/05 23:19, Alexander Hall wrote: I have not really seen any reason not to, other than that it is not enabled by default. Here's one reason you might sometimes not want it: space of deleted files isn't recovered until the delayed updates have been written out. This is particularly apparent if you want to upgrade to 3.9 on a system where /usr is barely large enough (-:
Re: About soft updates
Josh Grosse wrote: On Wed, Jul 05, 2006 at 11:19:04PM +0200, Alexander Hall wrote: Hi, I've been trying to find out whether to enable soft updates or not, and I have not really seen any reason not to, other than that it is not enabled by default. In order not to spread (or consume) FUD, I would like to know if soft updates are considered reliable and in which situations, if any, soft updates are specifically recommended or not recommended. Was the answer in FAQ 14.5 insufficient? :) ! Thus, a large performance increase is seen in disk writing performance. - So would mounting async, but I would not use that for any important data. ! Note to sparc users: Do not enable soft updates on sun4 or sun4c machines. /.../ - I'm on i386. Yes, FAQ 14.5 was insufficient.
Re: About soft updates
Stuart Henderson wrote: On 2006/07/05 23:19, Alexander Hall wrote: I have not really seen any reason not to, other than that it is not enabled by default. Here's one reason you might sometimes not want it: space of deleted files isn't recovered until the delayed updates have been written out. This is particularly apparent if you want to upgrade to 3.9 on a system where /usr is barely large enough (-: Been there too. 256MB CF card on soekris 4801. Much trouble also came from upgrading a running system, though, which made the old libs and other binaries, albeit unlinked, occupy a lot of precious disk space. So - unpacking failed, but only after fsck'ing up the login libs. Thank g*d I kept that serial cable and bsd.rd handy. :)
