NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: install/50033: WABPL(4) is not enabled by default in sysinst(8)



The following reply was made to PR install/50033; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: install/50033: WABPL(4) is not enabled by default in sysinst(8)
Date: Sun, 6 Sep 2015 00:33:10 +0000

 On Sat, Jul 04, 2015 at 02:40:01PM +0000, Martin Husemann wrote:
  >  Thanks for the PR, indeed releng/core should discuss and document the
  >  default for -7 ASAP.
 
 ...yes, since while it has problems, without it things are really
 slow and still have problems.
 
  >  But just for documentation purposes, let me point out (from my personal
  >  memory/understanding) a few things:
  >  
  >   - There have been a few stability issues attributed to wapbl. I think they
  >     have been fixed (either in wapbl or the underlying disk drivers). These
  >     were probably the main reason hinted as "far too dangerous" in the
  >     disabling commit
 
 I don't think so - I think that was about file data blocks. Anyway,
 while there have been intermittent problems (50159 apparently being
 one) it's not clear to me that there's any more trouble than with
 ffs-without-wapbl.
 
  >   - There is the still open issue with deleting a large file taking
  >     ages and blocking the kernel completely during that time
 
 Yes, plus the related issue that panics instead.
 
  >   - There are (depending on hardware) serious performance issues that
  >     can be avoided by setting vfs.wapbl.flush_disk_cache=0 (but that
  >     is not safe if there is no external UPS or the machine is a notebook)
 
 Is there a PR specifically on this? I don't remember one, and it would
 be good to collect up the information somewhere.
 
  >   - There is a (I would call it nearly phillosophical) issue with
  >     wapbl not being a full log file system (but only meta data is loged),
  >     so on crashes you may lose all contents of recently touched files -
  >     often showing up as a "cvs update" running while the system paniced
  >     leaving many 0 sized or truncated files around.
 
 This I think was the motivation for turning it off; but remember that
 ffs-without-wapbl has the same problem. It just runs slower and
 therefore leaves you with fewer garbaged files...
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost
 


Home | Main Index | Thread Index | Old Index