linux-kernel - Re: [patch 8/8] fs: add i_op->sync

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 6 Jan 2011 15:49:11 -0500
From:	Christoph Hellwig <hch@...radead.org>
To:	Nick Piggin <npiggin@...nel.dk>
Cc:	Christoph Hellwig <hch@...radead.org>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [patch 8/8] fs: add i_op->sync_inode

On Tue, Jan 04, 2011 at 08:52:31PM +1100, Nick Piggin wrote:
> OK I missed that part about not requiring dirty metadata to be written,
> just currently ongoing async operations. But then I don't understand how
> it would be used by nfsd, how does nfsd start some async operation on
> the inode metadata such that ->commit_metadata would do anything useful
> for it?

NFSD calls various inode operations (create/mkdir/mknod/link/symlink/
rename/unlink/rmdir/setattr) and then requires those operations to be
on disk before completing the request to the client, but it does not
require other dirty state to be written (data, unlogged size
or timestamp updates).  Take a look at the XFS implementation: it just
checks if the inode is still pinned (that is in the in-memory log, but
not commited to disk) and if so forces the log up to the log buffer
that contains the last changes to the inode.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/