[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E75AEFD.105@gmail.com>
Date: Sun, 18 Sep 2011 10:42:37 +0200
From: Marco Stornelli <marco.stornelli@...il.com>
To: jeff.liu@...cle.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
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.
--
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