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 for Android: free password hash cracker in your pocket

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

Message-ID: <20110315101155.GO15097@dastard>
Date:	Tue, 15 Mar 2011 21:11:55 +1100
From:	Dave Chinner <david@...morbit.com>
To:	Sage Weil <sage@...dream.net>
Cc:	Indan Zupancic <indan@....nu>, Greg KH <greg@...ah.com>,
	Jonathan Nieder <jrnieder@...il.com>,
	Arnd Bergmann <arnd@...db.de>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	"Aneesh Kumar K. V" <aneesh.kumar@...ux.vnet.ibm.com>,
	akpm@...ux-foundation.org, 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 Sun, Mar 13, 2011 at 09:29:17PM -0700, Sage Weil wrote:
> On Mon, 14 Mar 2011, Indan Zupancic wrote:
> > 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.
> 
> How about the man page below?  I tried to avoid the somewhat antiquated 
> implementation specific terminology in the sync(2) man page.
> 
> I think adding this functionality into sync_file_range(2) is forcing 
> unrelated functionality into an existing interface; sync_file_range 
> operates on _files_, not an entire file system.  With each API addition it 
> is more important to make the interface simple and intuitive than to 
> minimize the size of our patches.  IMO that's why a new syscall is 
> preferable to, say, an equivalent ioctl.
> 
> Thanks-
> sage
> 
> 
> .TH SYNCFS 2 2011-03-13 "Linux" "Linux Programmer's Manual"
> .SH NAME
> syncfs \- commit cached file system state to stable storage
> .SH SYNOPSIS
> .B #include <unistd.h>
> .sp
> .B void syncfs(int fd);
> .SH DESCRIPTION
> .BR syncfs ()
> flushes any cached data modifications to the file system containing the 
> file referenced by the file descriptor
> .I fd
> to stable storage (usually a disk).  This includes the results of any
> file modifications or other file system operations that have completed
> prior to the call to
> .BR syncfs(2).
> This is similar to 
> .BR sync(2),
> but will commit changes for only a single file system instead of all
> mounted file systems.
> .SH ERRORS
> This function is always successful.

Perhaps we should consider propagating errors out to the user
application rather than discarding them in kernel and pretending we
can't ever have a write error?

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
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/