On Tue, Nov 15, 2011 at 06:18:21AM -0500, tao.peng at emc.com wrote: > > On Tue, Nov 15, 2011 at 04:18:52PM +0800, Liu Yuan wrote: > > > Umm, seems useless, I just squeeze it to the code path. any noticeable > > > performance penalty? > > > > With the current O_SYNC I/O model it at least means an additional log > > force, which on disks will be very noticeable. So unless you really > > see a difference in I/O patterns don't do it. > Just out of curiosity, won't fallocate() be a better hint to underlying file system which can then create a better on disk layout? With O_SYNC IO it forces allocation on each write... Currently sheepdog does not support a writeback cache model yet, so we have to use O_SYNC everywhere. Even without that it will not provide a benefit for any reaosnable filesystem. For O_DIRECT I/O (which I would recommend for sheepdog nodes) the filesystem always sees the whole I/O and thus can trivially allocate one extent for the object. For buffered I/O the filesystem writepage method sees that the whole object is in delayed allocation state and can convert the whole extent to a real extent (at least that's what XFS does). |