Re: Proposal to enable WAPBL by default for 10.0

2020-09-03 Thread Reinoud Zandijk
On Thu, Jul 23, 2020 at 11:06:27AM +0200, Hauke Fath wrote: > On Thu, 23 Jul 2020 07:45:08 +0200, Michał Górny wrote: > > How does that compare to the level of damage non-journaled FFS takes? > > From then on, the sandbox was easily recoverable after every panic. It > turned out fsck times on a

Re: Proposal to enable WAPBL by default for 10.0

2020-07-27 Thread David Holland
On Sun, Jul 26, 2020 at 11:20:37PM +, m...@netbsd.org wrote: > > To be explicit: > > > > It is the same underly problem either way, and it is worse in practice > > with WAPBL than without because WAPBL ffs runs faster than non-WAPBL > > ffs and thus accumulates more unwritten blocks. >

Re: Proposal to enable WAPBL by default for 10.0

2020-07-27 Thread Roy Marples
On 27/07/2020 11:58, nia wrote: Of course, it would also be nice to have the option of more filesystems in sysinst (ZFS, LFS in 10 assuming the remaining deadlocks mainly effect removable media - taylor?), and a noatime option for flash media. Until we get bootloader support for ZFS we might

Re: Proposal to enable WAPBL by default for 10.0

2020-07-27 Thread nia
It feels like we could avoid the controversy of whether it should be enabled by default by making it an option in sysinst. Of course, it would also be nice to have the option of more filesystems in sysinst (ZFS, LFS in 10 assuming the remaining deadlocks mainly effect removable media - taylor?),

Re: Proposal to enable WAPBL by default for 10.0

2020-07-26 Thread Jason Thorpe
> On Jul 26, 2020, at 4:20 PM, m...@netbsd.org wrote: > > It looks like this difference is because FFS doesn't flush the disk > cache often, but if WAPBL is enabled, it does on every log write. Do you mean by issuing a SYNCHRONIZE_CACHE or similar command? Be aware that there are a lot of

Re: Proposal to enable WAPBL by default for 10.0

2020-07-26 Thread maya
On Thu, Jul 23, 2020 at 08:56:14PM +, David Holland wrote: > On Thu, Jul 23, 2020 at 07:45:08AM +0200, Micha? G?rny wrote: > > > > Rationale: the default filesystem (FFS) without WAPBL is more prone to > > > > data loss. > > > > > > It is not, unfortunately. We had WAPBL on by default

Re: Proposal to enable WAPBL by default for 10.0

2020-07-23 Thread David Holland
On Thu, Jul 23, 2020 at 07:45:08AM +0200, Micha? G?rny wrote: > > > Rationale: the default filesystem (FFS) without WAPBL is more prone to > > > data loss. > > > > It is not, unfortunately. We had WAPBL on by default some time back > > and eventually switched it off. > > > > The problem

Re: Proposal to enable WAPBL by default for 10.0

2020-07-23 Thread Jonathan A. Kollasch
On Wed, Jul 22, 2020 at 11:24:16PM +0200, Kamil Rytarowski wrote: > I propose to enable WAPBL ("log" in fstab(5)) by default for 10.0 and newer. I oppose such a move. I will not be able to support any such change until https://gnats.netbsd.org/47231 is satisfactorily resolved. Jonathan

Re: Proposal to enable WAPBL by default for 10.0

2020-07-23 Thread Taylor R Campbell
> Date: Thu, 23 Jul 2020 08:43:04 -0400 > From: Greg Troxel > > Taylor R Campbell writes: > > [lots of good points, no disagreement] > > If /etc/master.passwd is ending up with junk, that's a clue that code > that updates it isn't doing the write secondary file, fysnc it, rename, > approach.

Re: Proposal to enable WAPBL by default for 10.0

2020-07-23 Thread Greg Troxel
Taylor R Campbell writes: [lots of good points, no disagreement] If /etc/master.passwd is ending up with junk, that's a clue that code that updates it isn't doing the write secondary file, fysnc it, rename, approach. As I understand it with POSIX filesystems you have to do that because there

Re: Proposal to enable WAPBL by default for 10.0

2020-07-23 Thread Hauke Fath
On Thu, 23 Jul 2020 07:45:08 +0200, Michał Górny wrote: >> The problem is that because it still doesn't do anything about >> journaling or preserving file contents, but runs a lot faster, it >> loses more data when interrupted. > > How does that compare to the level of damage non-journaled FFS

Re: Proposal to enable WAPBL by default for 10.0

2020-07-23 Thread Taylor R Campbell
> Date: Thu, 23 Jul 2020 07:45:08 +0200 > From: Michał_Górny > > On Thu, 2020-07-23 at 05:17 +, David Holland wrote: > > The problem is that because it still doesn't do anything about > > journaling or preserving file contents, but runs a lot faster, it > > loses more data when interrupted.

Re: Proposal to enable WAPBL by default for 10.0

2020-07-22 Thread Michał Górny
On Thu, 2020-07-23 at 05:17 +, David Holland wrote: > On Wed, Jul 22, 2020 at 11:24:16PM +0200, Kamil Rytarowski wrote: > > I propose to enable WAPBL ("log" in fstab(5)) by default for 10.0 and > newer. > > [...] > > > > Rationale: the default filesystem (FFS) without WAPBL is more prone

Re: Proposal to enable WAPBL by default for 10.0

2020-07-22 Thread David Holland
On Thu, Jul 23, 2020 at 05:17:33AM +, David Holland wrote: > The problem is that because it still doesn't do anything about > journaling or preserving file contents, but runs a lot faster, it > loses more data when interrupted. Note since someone already asked: that should be read as

Re: Proposal to enable WAPBL by default for 10.0

2020-07-22 Thread David Holland
On Wed, Jul 22, 2020 at 11:24:16PM +0200, Kamil Rytarowski wrote: > I propose to enable WAPBL ("log" in fstab(5)) by default for 10.0 and newer. > [...] > > Rationale: the default filesystem (FFS) without WAPBL is more prone to > data loss. It is not, unfortunately. We had WAPBL on by

Proposal to enable WAPBL by default for 10.0

2020-07-22 Thread Kamil Rytarowski
I propose to enable WAPBL ("log" in fstab(5)) by default for 10.0 and newer. WAPBL - Write Ahead Physical Block Logging file system journaling More info on WAPBL in wapbl(4). https://netbsd.gw.com/cgi-bin/man-cgi?wapbl++NetBSD-current Rationale: the default filesystem (FFS) without WAPBL is