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
| ||
|
Date: Fri, 11 Mar 2011 20:10:01 -0600 From: Jonathan Nieder <jrnieder@...il.com> To: Indan Zupancic <indan@....nu> Cc: 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>, 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 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. > In this case it's just a performance improvement over sync(2). It doesn't > add a new feature. Main argument given for the performance problem seems > to be "NFS can be slow". Anything else? Huh? It is not just the speed of the sync --- unnecessary writeback will cause wear on your thumbdrive, eat up your laptop battery, and kill I/O performance in other tasks running at the same time. I'm afraid I don't understand what you're saying here at all. Would you say that fsync is superfluous, too? Jonathan -- 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/
Powered by blists - more mailing lists