Date: Tue, 12 Sep 2006 11:40:31 +0200 From: Ivan Voras <ivoras@fer.hr> To: freebsd-stable@freebsd.org Subject: Re: gjournal and Softupdates Message-ID: <ee5vat$fcb$1@sea.gmane.org> In-Reply-To: <45066E19.2040405@kuehlbox.de> References: <45066E19.2040405@kuehlbox.de>
next in thread | previous in thread | raw e-mail | index | archive | help
bsd@kuehlbox.de wrote: > Only bgfsck > has todo a snapshot and cleanup "unused" space that got lost cause the > SU did not finish as the crash occured. > > Maybe someone can give me some light into that :). I always tought that > *BSD don't need a journaling FS as it has already SU Soft-updates was a good idea that was implemented a bit too late (with regards to development in journaling and file system technologies), and now there are several problems with it: - [bg]fsck is still needed, and it takes way too long on large (terabyte-size) file systems. This was not a problem with small file systems when SU was designed. - bgfsck relies on snapshots, and there still are several problems with those (judging from information on mailing lists, not personal experience): they take too long to create on large file systems, there are problems with taking snapshots when the drive is almost full, and (possibly? don't remember exactly now) some NFS issues with either the snapshot or the underlying file system. - (most?) kernel developers tend to disable bgfsck completely on the file systems actively used during development because of possible panic during testing new code while bgfsck is still running, and normal fsck takes too long - todays desktop drives can lie about writing data. SoftUpdates relies on some assumptions about when the data is physically written to media, and those are not always valid today - every now and then there appear some anecdotal evidence that file systems do get destroyed even with SoftUpdates, which are probably related to the previous point, but it can't be investigated - AFAIK the addition of SoftUpdates to file system code made file system code more than usually complex, with bugs that are discovered even now. The basic idea behind SU is good and valid, but judging from side-effects of its practical implementation, right now journaling appears to be a simpler and more effective solution to the problem.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ee5vat$fcb$1>