xfs
[Top] [All Lists]

Re: [PATCH] xfs_io: actually issue 0 size writes

To: Felix Blyakher <felixb@xxxxxxx>
Subject: Re: [PATCH] xfs_io: actually issue 0 size writes
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Thu, 13 Aug 2009 19:15:45 -0500
Cc: xfs mailing list <xfs@xxxxxxxxxxx>
In-reply-to: <1CDE853D-47DB-4E76-8D8F-DA1B77CC1F54@xxxxxxx>
References: <4A849096.1010600@xxxxxxxxxxx> <1CDE853D-47DB-4E76-8D8F-DA1B77CC1F54@xxxxxxx>
User-agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
Felix Blyakher wrote:
> On Aug 13, 2009, at 5:15 PM, Eric Sandeen wrote:
> 
>> While testing some stuff in generic_write_checks() in the
>> kernel I realized that you can't actually use xfs_io to send
>> a 0-byte write in.  This is actually a condition worth testing:
>>
>>       If  count  is zero and fd refers to a regular file,
>>       then write() may return a failure status if one  of
>>       the  errors  below  is  detected.  If no errors are
>>       detected, 0 will be returned  without  causing  any
>>       other  effect.
> 
> As I understand the desire to be able to issue 0 size writes
> from xfs_io is to test the possibility of writing to a given fd.
> What kind of errors would you expect to test for?

In general EFBIG or ENOSPC.

This sort of thing in generic_write_checks():

        if (unlikely(*pos >= inode->i_sb->s_maxbytes)) {
                if (*count || *pos > inode->i_sb->s_maxbytes) {
                     return -EFBIG;
                }
                /* zero-length writes at ->s_maxbytes are OK */
        }

Although I'm a little confused about why "*pos == s_maxbytes" is ok; I
thought s_maxbytes was a count/size whereas pos is an offset, so it
seems to me that pos == s_maxbytes is one past the max.  But anyway,
that's mostly unrelated to the patch in this thread.  :)

-Eric

> Otherwise looks good.
> 
> Felix


<Prev in Thread] Current Thread [Next in Thread>