[Top] [All Lists]

Re: [patch 0/9] writeback data integrity and other fixes (take 3)

To: Jamie Lokier <jamie@xxxxxxxxxxxxx>
Subject: Re: [patch 0/9] writeback data integrity and other fixes (take 3)
From: Ric Wheeler <ricwheeler@xxxxxxxxx>
Date: Wed, 29 Oct 2008 09:32:19 -0400
Cc: Nick Piggin <npiggin@xxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, linux-nfs@xxxxxxxxxxxxxxx, akpm@xxxxxxxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, Chris Mason <chris.mason@xxxxxxxxxx>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=HA1KBVG7mk/5f0JCHPh6uBtzyo4SbOW/Ir9kFqbyW7g=; b=p+/cLn5abWcUcOWDlCgRHJsqOtsn1BJ7JFa6KQmxV92PIUKOz9XPsPBobxZ0otHtat KZbPa6+LdSpJu2jojMeWki/c7fNN7Z9gDZu0+2hTaovvv0027cdZH6emPRv6+ARRsDgG gP6AzsAOhHWaHAapeHRJIf9LmXuA7GFKIxPW8=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=HQzGR9UXephigYB9SObcky3ML8JjzoQ5apeMZiYr5tiJ8D3tHViwfxdVhbHSExFGNP 8t553j9MOLgzmDPYHQ4ccCl5f2fKpLz1eWaF1gOt7Z14g5WO6eW4UW6Y6hI42G359Dqr z9RC99iYb78CXQqjq5dndPxxZoP/uzGMidoSk=
In-reply-to: <20081029122234.GE846@xxxxxxxxxxxxx>
References: <20081028144715.683011000@xxxxxxx> <20081028153953.GB3082@xxxxxxxxxxxxx> <20081028222746.GB4985@disturbed> <20081029001653.GF15599@xxxxxxxxxxxxx> <20081029031645.GE4985@disturbed> <20081029091203.GA32545@xxxxxxxxxxxxx> <20081029092143.GA5953@xxxxxxxxxxxxx> <20081029094417.GA21824@xxxxxxxxxxxxx> <20081029103029.GC5953@xxxxxxxxxxxxx> <20081029122234.GE846@xxxxxxxxxxxxx>
User-agent: Thunderbird (X11/20081009)
Jamie Lokier wrote:
Nick Piggin wrote:
On Wed, Oct 29, 2008 at 05:44:17AM -0400, Christoph Hellwig wrote:
On Wed, Oct 29, 2008 at 10:21:43AM +0100, Nick Piggin wrote:
Please do.
Well, there's one stumling block I haven't made progress on yet:

I've changed the prototype of ->fsync to lose the dentry as we should
always have a valid file struct.  Except that nfsd doesn't on
directories.  So I either need to fake up a file there, or bail out
and add a ->dir_sync export operation that needs just a dentry.
OK. I don't know much about hthat code, but I would think nfsd
should look as close to the syscall layer as possible. I guess
there must be something prohibitive (some protocol semantics?).

Is there anything that particularly makes it a file operation
as opposed to an inode operation?

In principle, is fsync() required to flush all dirty data written
through any file descriptor ever, or just dirty data written through
the file descriptor used for fsync()?

-- Jamie

Is a pointer to what seems to be the official posix spec for this - it is definitely per file descriptor, not per file system, etc...

What can happen by side effect (depending on the implementation) is that you can actually force out all data for any file. I found that you can approach non-fsync speeds for an fsync per file workload by simply writing all of the files out, then going back and fsync'ing them one at a time (last file first makes a bit of a difference). With that technique, you do get the hard promise of full data integrity and high speed. This is useful when you want to do bulk writes (tar, etc)


<Prev in Thread] Current Thread [Next in Thread>