linux-kernel - Re: [PATCH v3] introduce sys_syncfs to sync a single file system

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]

Message-Id: <20110314131042.5a7fb32f.akpm@linux-foundation.org>
Date:	Mon, 14 Mar 2011 13:10:42 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	"Indan Zupancic" <indan@....nu>
Cc:	"Greg KH" <greg@...ah.com>, "Jonathan Nieder" <jrnieder@...il.com>,
	"Arnd Bergmann" <arnd@...db.de>, "Sage Weil" <sage@...dream.net>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	"Aneesh Kumar K. V" <aneesh.kumar@...ux.vnet.ibm.com>,
	linux-api@...r.kernel.org, mtk.manpages@...il.com,
	viro@...iv.linux.org.uk, hch@....de, l@...per.es
Subject: Re: [PATCH v3] introduce sys_syncfs to sync a single file system

On Mon, 14 Mar 2011 02:56:52 +0100 (CET)
"Indan Zupancic" <indan@....nu> wrote:

> On Sat, March 12, 2011 18:32, Greg KH wrote:
> > On Fri, Mar 11, 2011 at 08:10:01PM -0600, Jonathan Nieder wrote:
> >> Indan Zupancic wrote:
> >>
> >> > I'm not pushing for any official convention, just what seems good taste.
> >>
> >> In cases like this, conventions (consistency and best practices) are
> >> very important.
> >>
> >> > Less code added, less bloat. Architecture independent, no need to update
> >> > all system call tables everywhere (all archs, libc versions and strace).
> >> > Two files changed, instead of 7 (which only hooks up x86).
> >>
> >> Thanks for explaining.  Those do seem like good reasons to use a ioctl
> >> instead of a new syscall.
> >
> > No, make it a syscall, it's more obvious and will be documented much
> > better.
> 
> There is no such guarantee. Everyone seems to want to add this new syncfs,
> but it's not even defined what it does. "Same as sync, but only on one fs"
> is IMHO not good enough, because sync's behaviour is pretty badly documented,
> and that's a system call. The sync_file_range argument effects are quite
> well defined, on the other hand, unlike sync behaviour. You're right for
> ioctls though.

I think the semantics of sync are easily enough defined, even if
they're not well-defined in the documentation: all data which was dirty
at the time sync() was called will be written back and accessible when
the sync() returns.

I do agree that this should be a standalone syscall, not grafted into
sync_file_range() or into an ioctl.

That being said, we have two similar-looking-but-quite-different "sync"
concepts in the kernel.  One is "sync for data integrity" and the other
is "sync to reduce the dirty memory load".  The latter is not a data
integrity thing - it is a resource management thing.

There might one day be a requirement to be able to initiate a
resource-management-style writeback against a whole filesystem.  When
that happens, we'll regret not having added a "mode" argument to
sys_syncfs().

Or maybe not - given that we're syncing the entire fs and that
sync_filesystem() does the two-pass "write for data cleaning then write
for data integrity" thing, it could be that a syncfs-for-data-cleaning
operation has little performance benefit over a
syncfs-for-data-integrity operation.

--
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/