[Sheepdog] [PATCH] sheep: unify create_and_write logic for cow and regular object

[tao.peng at emc.com]

> -----Original Message-----
> From: Christoph Hellwig [mailto:hch at infradead.org]
> Sent: Tuesday, November 15, 2011 8:53 PM
> To: Peng, Tao
> Cc: hch at infradead.org; sheepdog at lists.wpkg.org; namei.unix at gmail.com
> Subject: Re: [Sheepdog] [PATCH] sheep: unify create_and_write logic for cow and
> regular object
> 
> 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).
With buffer IO and delayed allocation, I agree it can see the whole object. But DIO... do you plan to buffer the whole object in memory and send it down in one write system call? With current 4MB objects, it seems reasonable. But how about future large objects? I would think it makes sense to fallocate in DIO case...

Cheers,
Tao