[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <8444301C-856F-44FA-94A3-D3583DFA0FFB@oracle.com>
Date: Sun, 18 Sep 2011 18:33:38 +0800
From: Jeff liu <jeff.liu@...cle.com>
To: Marco Stornelli <marco.stornelli@...il.com>
Cc: Andi Kleen <ak@...ux.intel.com>,
Andreas Dilger <adilger@...ger.ca>,
Christoph Hellwig <hch@...radead.org>,
Andi Kleen <andi@...stfloor.org>,
"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-btrfs@...r.kernel.org" <linux-btrfs@...r.kernel.org>
Subject: Re: [PATCH 1/7] BTRFS: Fix lseek return value for error
在 2011-9-18,下午4:42, Marco Stornelli 写道:
> Il 18/09/2011 09:29, Jeff Liu ha scritto:
>> Hi Andreas and Andi,
>>
>> Thanks for your comments.
>>
>> On 09/18/2011 09:46 AM, Andi Kleen wrote:
>>
>>>>> with an additional improvement if the offset is larger or equal to the
>>>>> file size, return -ENXIO in directly:
>>>>>
>>>>> if (offset>= inode->i_size) {
>>>>> mutex_unlock(&inode->i_mutex);
>>>>> return -ENXIO;
>>>>> }
>>>>
>>>> Except that is wrong, because it would then be impossible to write sparse files.
>>
>> Per my tryout, except that, if the offset>= source file size, call
>> lseek(fd, offset, SEEK_DATA/SEEK_HOLE) against Btrfs will always return
>> the total file size rather than -ENXIO. however, our desired result it
>> -ENXIO in this case, Am I right?
>>
>
> Yes, ENXIO should be the operation result.
Thanks for your kind confirmation.
-Jeff
--
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