Date: Fri, 11 Feb 2005 23:39:03 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Julian Elischer <julian@elischer.org> Cc: fs@freebsd.org Subject: Re: Journalling FS and Soft Updates comparision Message-ID: <20050211231020.S1985@epsplex.bde.org> In-Reply-To: <420BE69F.6070009@elischer.org> References: <20050210030119.GD29396@alzatex.com> <420AD3A7.3000102@freebsd.org><420BE69F.6070009@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 10 Feb 2005, Julian Elischer wrote:
> uh.. isn't this backwards?
>
> Dan Nelson wrote:
>
> >
> >This is the big drawback to softupdates for me. You run the risk of
> >losing the last `sysctl kern.metadelay` seconds worth of files, because
> >of all the state that softupdates keeps in RAM.
>
> kern.filedelay: 30
> kern.dirdelay: 29
> kern.metadelay: 28
>
> according to this we write the metadata first and then the directory
> block and
> then the file data..
The kern.metadata sysctl has nothing to do with the delay for syncing
metadata, unlike what its comment says. It controls the delay for
syncing files of type VCHR. Since these files have no data to sync,
only metadata can be synced for them. In -current and mostly in
RELENG_5, since phk has completed or almost completed axing support
for device files outside of devfs, these files usually have nothing
to sync.
The kern.filedelay sysctl contrils the delay for syncing files of type VDIR
(directories) and the kern.filedelay sysctl controls the delay for syncing
files of type VREG (regular files).
> This is just wrong. In softupdates you want to have your data down
> before you do
> your metadata write, and you need to have your directory block written
> last of all.
Hopefully this (and correct order for metadata) is controlled by
dependencies. The syncer alone can't control the order since files
may be synced asynchronously relative to the syncer via fsync(2) or
for recycling vnodes, etc.
> When I committed the softupdates code for Kirk, I think that the numbers
> were:
> data in 10 seconds, metadata in 15 and directory block in 20.
> (from memory).
That commit (vfs_subr.c 1.201, etc.) is hard to find and understand because
it was a mega-commit with no details (not even the keyowrd "soft") in its
log message. It has only syncer_maxdelay = 32 and syncer_delay = 30, and
some magic scaling of these. The current numbers were added in rev.1.201.
It is easy to see what the old scaling was in the diff for that:
syncdelay / 2 -> dirdelay (default 15 -> 29)
syncdelay / 3 -> metadelay ( 10 -> 28)
sycdelay -> filedelay ( 30 -> 30)
So the numbers have been bunched up but not reordered.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050211231020.S1985>