* punch-hole should go beyond i_size
@ 2012-01-12 1:02 Hugh Dickins
2012-01-12 2:55 ` Dave Chinner
0 siblings, 1 reply; 10+ messages in thread
From: Hugh Dickins @ 2012-01-12 1:02 UTC (permalink / raw)
To: Allison Henderson; +Cc: linux-ext4
Hi Allison,
In thinking about fallocate() on tmpfs, I cross-check with ext4
and find this bug in its implementation of FALLOC_FL_PUNCH_HOLE:
rm -f temp
fallocate -l 4096 temp
du temp # shows 4, right
fallocate -p -l 4096 temp
du temp # shows 0, right
rm -f temp
fallocate -n -l 4096 temp
du temp # shows 4, right
fallocate -p -l 4096 temp
du temp # shows 4, wrong
rm temp
ext4_ext_punch_hole() contains /* No need to punch hole beyond i_size */
early return, and trimming to i_size below, but forgets that the other
variety of fallocate(), with FALLOC_FL_KEEP_SIZE set, may have allocated
blocks beyond i_size. They can be removed with ftruncate(), but it is
unexpected for fallocate() not to undo its own work, and xfs does so.
Hugh
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: punch-hole should go beyond i_size
2012-01-12 1:02 punch-hole should go beyond i_size Hugh Dickins
@ 2012-01-12 2:55 ` Dave Chinner
2012-01-12 16:23 ` Allison Henderson
0 siblings, 1 reply; 10+ messages in thread
From: Dave Chinner @ 2012-01-12 2:55 UTC (permalink / raw)
To: Hugh Dickins; +Cc: Allison Henderson, linux-ext4
On Wed, Jan 11, 2012 at 05:02:12PM -0800, Hugh Dickins wrote:
> Hi Allison,
>
> In thinking about fallocate() on tmpfs, I cross-check with ext4
> and find this bug in its implementation of FALLOC_FL_PUNCH_HOLE:
>
> rm -f temp
> fallocate -l 4096 temp
> du temp # shows 4, right
> fallocate -p -l 4096 temp
> du temp # shows 0, right
> rm -f temp
> fallocate -n -l 4096 temp
> du temp # shows 4, right
> fallocate -p -l 4096 temp
> du temp # shows 4, wrong
> rm temp
>
> ext4_ext_punch_hole() contains /* No need to punch hole beyond i_size */
> early return, and trimming to i_size below, but forgets that the other
> variety of fallocate(), with FALLOC_FL_KEEP_SIZE set, may have allocated
> blocks beyond i_size. They can be removed with ftruncate(), but it is
> unexpected for fallocate() not to undo its own work, and xfs does so.
I'm pretty sure that's a bug as XFS allows punching holes in extents
beyond EOF.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: punch-hole should go beyond i_size
2012-01-12 2:55 ` Dave Chinner
@ 2012-01-12 16:23 ` Allison Henderson
2012-01-13 0:21 ` Hugh Dickins
2012-05-13 21:13 ` Hugh Dickins
0 siblings, 2 replies; 10+ messages in thread
From: Allison Henderson @ 2012-01-12 16:23 UTC (permalink / raw)
To: Dave Chinner; +Cc: Hugh Dickins, linux-ext4
On 01/11/2012 07:55 PM, Dave Chinner wrote:
> On Wed, Jan 11, 2012 at 05:02:12PM -0800, Hugh Dickins wrote:
>> Hi Allison,
>>
>> In thinking about fallocate() on tmpfs, I cross-check with ext4
>> and find this bug in its implementation of FALLOC_FL_PUNCH_HOLE:
>>
>> rm -f temp
>> fallocate -l 4096 temp
>> du temp # shows 4, right
>> fallocate -p -l 4096 temp
>> du temp # shows 0, right
>> rm -f temp
>> fallocate -n -l 4096 temp
>> du temp # shows 4, right
>> fallocate -p -l 4096 temp
>> du temp # shows 4, wrong
>> rm temp
>>
>> ext4_ext_punch_hole() contains /* No need to punch hole beyond i_size */
>> early return, and trimming to i_size below, but forgets that the other
>> variety of fallocate(), with FALLOC_FL_KEEP_SIZE set, may have allocated
>> blocks beyond i_size. They can be removed with ftruncate(), but it is
>> unexpected for fallocate() not to undo its own work, and xfs does so.
>
> I'm pretty sure that's a bug as XFS allows punching holes in extents
> beyond EOF.
>
> Cheers,
>
> Dave.
Oh I see, I'll take a look at it, I think it will be ok to just take out
the early return. Thx!
Allison
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: punch-hole should go beyond i_size
2012-01-12 16:23 ` Allison Henderson
@ 2012-01-13 0:21 ` Hugh Dickins
2012-01-13 3:18 ` Allison Henderson
2012-05-13 21:13 ` Hugh Dickins
1 sibling, 1 reply; 10+ messages in thread
From: Hugh Dickins @ 2012-01-13 0:21 UTC (permalink / raw)
To: Allison Henderson; +Cc: Dave Chinner, linux-ext4
On Thu, 12 Jan 2012, Allison Henderson wrote:
> On 01/11/2012 07:55 PM, Dave Chinner wrote:
> > On Wed, Jan 11, 2012 at 05:02:12PM -0800, Hugh Dickins wrote:
> > >
> > > ext4_ext_punch_hole() contains /* No need to punch hole beyond i_size */
> > > early return, and trimming to i_size below, but forgets that the other
> > > variety of fallocate(), with FALLOC_FL_KEEP_SIZE set, may have allocated
> > > blocks beyond i_size. They can be removed with ftruncate(), but it is
> > > unexpected for fallocate() not to undo its own work, and xfs does so.
> >
> > I'm pretty sure that's a bug as XFS allows punching holes in extents
> > beyond EOF.
>
> Oh I see, I'll take a look at it, I think it will be ok to just take out the
> early return. Thx!
Thanks. And I've just noticed another, very easily fixed, error:
I believe those -ENOTSUPPs in ext4_punch_hole() should be -EOPNOTSUPPs.
Hugh
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: punch-hole should go beyond i_size
2012-01-13 0:21 ` Hugh Dickins
@ 2012-01-13 3:18 ` Allison Henderson
0 siblings, 0 replies; 10+ messages in thread
From: Allison Henderson @ 2012-01-13 3:18 UTC (permalink / raw)
To: Hugh Dickins; +Cc: Dave Chinner, linux-ext4
On 01/12/2012 05:21 PM, Hugh Dickins wrote:
> On Thu, 12 Jan 2012, Allison Henderson wrote:
>> On 01/11/2012 07:55 PM, Dave Chinner wrote:
>>> On Wed, Jan 11, 2012 at 05:02:12PM -0800, Hugh Dickins wrote:
>>>>
>>>> ext4_ext_punch_hole() contains /* No need to punch hole beyond i_size */
>>>> early return, and trimming to i_size below, but forgets that the other
>>>> variety of fallocate(), with FALLOC_FL_KEEP_SIZE set, may have allocated
>>>> blocks beyond i_size. They can be removed with ftruncate(), but it is
>>>> unexpected for fallocate() not to undo its own work, and xfs does so.
>>>
>>> I'm pretty sure that's a bug as XFS allows punching holes in extents
>>> beyond EOF.
>>
>> Oh I see, I'll take a look at it, I think it will be ok to just take out the
>> early return. Thx!
>
> Thanks. And I've just noticed another, very easily fixed, error:
> I believe those -ENOTSUPPs in ext4_punch_hole() should be -EOPNOTSUPPs.
>
> Hugh
>
Ah, I think youre right, I will change the error values. I have the
current solution running in a test right now, and will post the patch
when it comes up clean. Thx!
Allison Henderson
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: punch-hole should go beyond i_size
2012-01-12 16:23 ` Allison Henderson
2012-01-13 0:21 ` Hugh Dickins
@ 2012-05-13 21:13 ` Hugh Dickins
2012-05-15 21:36 ` Allison Henderson
1 sibling, 1 reply; 10+ messages in thread
From: Hugh Dickins @ 2012-05-13 21:13 UTC (permalink / raw)
To: Allison Henderson; +Cc: Dave Chinner, Theodore Ts'o, linux-ext4
On Thu, 12 Jan 2012, Allison Henderson wrote:
> On 01/11/2012 07:55 PM, Dave Chinner wrote:
> > On Wed, Jan 11, 2012 at 05:02:12PM -0800, Hugh Dickins wrote:
> > > Hi Allison,
> > >
> > > In thinking about fallocate() on tmpfs, I cross-check with ext4
> > > and find this bug in its implementation of FALLOC_FL_PUNCH_HOLE:
> > >
> > > rm -f temp
> > > fallocate -l 4096 temp
> > > du temp # shows 4, right
> > > fallocate -p -l 4096 temp
> > > du temp # shows 0, right
> > > rm -f temp
> > > fallocate -n -l 4096 temp
> > > du temp # shows 4, right
> > > fallocate -p -l 4096 temp
> > > du temp # shows 4, wrong
> > > rm temp
> > >
> > > ext4_ext_punch_hole() contains /* No need to punch hole beyond i_size */
> > > early return, and trimming to i_size below, but forgets that the other
> > > variety of fallocate(), with FALLOC_FL_KEEP_SIZE set, may have allocated
> > > blocks beyond i_size. They can be removed with ftruncate(), but it is
> > > unexpected for fallocate() not to undo its own work, and xfs does so.
> >
> > I'm pretty sure that's a bug as XFS allows punching holes in extents
> > beyond EOF.
> >
> > Cheers,
> >
> > Dave.
>
> Oh I see, I'll take a look at it, I think it will be ok to just take out the
> early return. Thx!
I see the -EOPNOTSUPPs have gone into 3.4's ext4_punch_hole() - thanks -
but the i_size issue remains unfixed. I wouldn't be surprised if it were
more complicated than you had hoped - I had no intention of trying a patch
myself! It's not an actual problem for me, but I thought I'd just send a
reminder, before I move out of the hole-punching business.
Hugh
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: punch-hole should go beyond i_size
2012-05-13 21:13 ` Hugh Dickins
@ 2012-05-15 21:36 ` Allison Henderson
2012-05-15 22:38 ` Hugh Dickins
0 siblings, 1 reply; 10+ messages in thread
From: Allison Henderson @ 2012-05-15 21:36 UTC (permalink / raw)
To: Hugh Dickins; +Cc: Dave Chinner, Theodore Ts'o, linux-ext4, Lukas Czerner
On 05/13/2012 02:13 PM, Hugh Dickins wrote:
> On Thu, 12 Jan 2012, Allison Henderson wrote:
>> On 01/11/2012 07:55 PM, Dave Chinner wrote:
>>> On Wed, Jan 11, 2012 at 05:02:12PM -0800, Hugh Dickins wrote:
>>>> Hi Allison,
>>>>
>>>> In thinking about fallocate() on tmpfs, I cross-check with ext4
>>>> and find this bug in its implementation of FALLOC_FL_PUNCH_HOLE:
>>>>
>>>> rm -f temp
>>>> fallocate -l 4096 temp
>>>> du temp # shows 4, right
>>>> fallocate -p -l 4096 temp
>>>> du temp # shows 0, right
>>>> rm -f temp
>>>> fallocate -n -l 4096 temp
>>>> du temp # shows 4, right
>>>> fallocate -p -l 4096 temp
>>>> du temp # shows 4, wrong
>>>> rm temp
>>>>
>>>> ext4_ext_punch_hole() contains /* No need to punch hole beyond i_size */
>>>> early return, and trimming to i_size below, but forgets that the other
>>>> variety of fallocate(), with FALLOC_FL_KEEP_SIZE set, may have allocated
>>>> blocks beyond i_size. They can be removed with ftruncate(), but it is
>>>> unexpected for fallocate() not to undo its own work, and xfs does so.
>>>
>>> I'm pretty sure that's a bug as XFS allows punching holes in extents
>>> beyond EOF.
>>>
>>> Cheers,
>>>
>>> Dave.
>>
>> Oh I see, I'll take a look at it, I think it will be ok to just take out the
>> early return. Thx!
>
> I see the -EOPNOTSUPPs have gone into 3.4's ext4_punch_hole() - thanks -
> but the i_size issue remains unfixed. I wouldn't be surprised if it were
> more complicated than you had hoped - I had no intention of trying a patch
> myself! It's not an actual problem for me, but I thought I'd just send a
> reminder, before I move out of the hole-punching business.
>
> Hugh
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Hi all,
I had a fix for this a while ago and I believe Lukas had rebased it when he was working on some punch hole optimizations, but Im not sure what happened to it after that. I think Lukas might still be working on that set? If not, I can take a peek at it again and see if I can get it updated and resent. Thx!
Allison Henderson
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: punch-hole should go beyond i_size
2012-05-15 21:36 ` Allison Henderson
@ 2012-05-15 22:38 ` Hugh Dickins
2012-05-16 6:14 ` Lukáš Czerner
0 siblings, 1 reply; 10+ messages in thread
From: Hugh Dickins @ 2012-05-15 22:38 UTC (permalink / raw)
To: Allison Henderson
Cc: Jan Kara, Dave Chinner, Theodore Ts'o, linux-ext4,
Lukas Czerner
On Tue, 15 May 2012, Allison Henderson wrote:
> On 05/13/2012 02:13 PM, Hugh Dickins wrote:
> > On Thu, 12 Jan 2012, Allison Henderson wrote:
> >> On 01/11/2012 07:55 PM, Dave Chinner wrote:
> >>> On Wed, Jan 11, 2012 at 05:02:12PM -0800, Hugh Dickins wrote:
> >>>> Hi Allison,
> >>>>
> >>>> In thinking about fallocate() on tmpfs, I cross-check with ext4
> >>>> and find this bug in its implementation of FALLOC_FL_PUNCH_HOLE:
> >>>>
> >>>> rm -f temp
> >>>> fallocate -l 4096 temp
> >>>> du temp # shows 4, right
> >>>> fallocate -p -l 4096 temp
> >>>> du temp # shows 0, right
> >>>> rm -f temp
> >>>> fallocate -n -l 4096 temp
> >>>> du temp # shows 4, right
> >>>> fallocate -p -l 4096 temp
> >>>> du temp # shows 4, wrong
> >>>> rm temp
> >>>>
> >>>> ext4_ext_punch_hole() contains /* No need to punch hole beyond i_size */
> >>>> early return, and trimming to i_size below, but forgets that the other
> >>>> variety of fallocate(), with FALLOC_FL_KEEP_SIZE set, may have allocated
> >>>> blocks beyond i_size. They can be removed with ftruncate(), but it is
> >>>> unexpected for fallocate() not to undo its own work, and xfs does so.
> >>>
> >>> I'm pretty sure that's a bug as XFS allows punching holes in extents
> >>> beyond EOF.
> >>>
> >>> Cheers,
> >>>
> >>> Dave.
> >>
> >> Oh I see, I'll take a look at it, I think it will be ok to just take out the
> >> early return. Thx!
> >
> > I see the -EOPNOTSUPPs have gone into 3.4's ext4_punch_hole() - thanks -
> > but the i_size issue remains unfixed. I wouldn't be surprised if it were
> > more complicated than you had hoped - I had no intention of trying a patch
> > myself! It's not an actual problem for me, but I thought I'd just send a
> > reminder, before I move out of the hole-punching business.
>
> Hi all,
>
> I had a fix for this a while ago and I believe Lukas had rebased it
> when he was working on some punch hole optimizations, but Im not sure
> what happened to it after that. I think Lukas might still be working
> on that set? If not, I can take a peek at it again and see if I can
> get it updated and resent. Thx!
>
> Allison Henderson
Thanks, Allison. I just added Jan to the Cc list to make sure he sees,
since we mentioned this in the inode_dio_wait thread (which I skilfully
directed to an almost disjoint set of addressees - though I expect he
already saw via linux-ext4).
Hugh
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: punch-hole should go beyond i_size
2012-05-15 22:38 ` Hugh Dickins
@ 2012-05-16 6:14 ` Lukáš Czerner
2012-05-16 18:09 ` Hugh Dickins
0 siblings, 1 reply; 10+ messages in thread
From: Lukáš Czerner @ 2012-05-16 6:14 UTC (permalink / raw)
To: Hugh Dickins
Cc: Allison Henderson, Jan Kara, Dave Chinner, Theodore Ts'o,
linux-ext4, Lukas Czerner
On Tue, 15 May 2012, Hugh Dickins wrote:
> Date: Tue, 15 May 2012 15:38:33 -0700 (PDT)
> From: Hugh Dickins <hughd@google.com>
> To: Allison Henderson <achender@linux.vnet.ibm.com>
> Cc: Jan Kara <jack@suse.cz>, Dave Chinner <david@fromorbit.com>,
> Theodore Ts'o <tytso@mit.edu>, linux-ext4@vger.kernel.org,
> Lukas Czerner <lczerner@redhat.com>
> Subject: Re: punch-hole should go beyond i_size
>
> On Tue, 15 May 2012, Allison Henderson wrote:
> > On 05/13/2012 02:13 PM, Hugh Dickins wrote:
> > > On Thu, 12 Jan 2012, Allison Henderson wrote:
> > >> On 01/11/2012 07:55 PM, Dave Chinner wrote:
> > >>> On Wed, Jan 11, 2012 at 05:02:12PM -0800, Hugh Dickins wrote:
> > >>>> Hi Allison,
> > >>>>
> > >>>> In thinking about fallocate() on tmpfs, I cross-check with ext4
> > >>>> and find this bug in its implementation of FALLOC_FL_PUNCH_HOLE:
> > >>>>
> > >>>> rm -f temp
> > >>>> fallocate -l 4096 temp
> > >>>> du temp # shows 4, right
> > >>>> fallocate -p -l 4096 temp
> > >>>> du temp # shows 0, right
> > >>>> rm -f temp
> > >>>> fallocate -n -l 4096 temp
> > >>>> du temp # shows 4, right
> > >>>> fallocate -p -l 4096 temp
> > >>>> du temp # shows 4, wrong
> > >>>> rm temp
> > >>>>
> > >>>> ext4_ext_punch_hole() contains /* No need to punch hole beyond i_size */
> > >>>> early return, and trimming to i_size below, but forgets that the other
> > >>>> variety of fallocate(), with FALLOC_FL_KEEP_SIZE set, may have allocated
> > >>>> blocks beyond i_size. They can be removed with ftruncate(), but it is
> > >>>> unexpected for fallocate() not to undo its own work, and xfs does so.
> > >>>
> > >>> I'm pretty sure that's a bug as XFS allows punching holes in extents
> > >>> beyond EOF.
> > >>>
> > >>> Cheers,
> > >>>
> > >>> Dave.
> > >>
> > >> Oh I see, I'll take a look at it, I think it will be ok to just take out the
> > >> early return. Thx!
> > >
> > > I see the -EOPNOTSUPPs have gone into 3.4's ext4_punch_hole() - thanks -
> > > but the i_size issue remains unfixed. I wouldn't be surprised if it were
> > > more complicated than you had hoped - I had no intention of trying a patch
> > > myself! It's not an actual problem for me, but I thought I'd just send a
> > > reminder, before I move out of the hole-punching business.
> >
> > Hi all,
> >
> > I had a fix for this a while ago and I believe Lukas had rebased it
> > when he was working on some punch hole optimizations, but Im not sure
> > what happened to it after that. I think Lukas might still be working
> > on that set? If not, I can take a peek at it again and see if I can
> > get it updated and resent. Thx!
> >
> > Allison Henderson
>
> Thanks, Allison. I just added Jan to the Cc list to make sure he sees,
> since we mentioned this in the inode_dio_wait thread (which I skilfully
> directed to an almost disjoint set of addressees - though I expect he
> already saw via linux-ext4).
>
> Hugh
Yes, we've been talking about this issue on LSF with Ted and the
conclusion is that we want to wait for the range locks to be ready.
This way we can avoid taking imutex for the punch hole when punching
beyond isize which we would have to do otherwise.
I am not sure how big of an issue this is, probably not so big. If
we can not wait for the range locks, I can make a patch with imutex
protection.
Thanks!
-Lukas
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: punch-hole should go beyond i_size
2012-05-16 6:14 ` Lukáš Czerner
@ 2012-05-16 18:09 ` Hugh Dickins
0 siblings, 0 replies; 10+ messages in thread
From: Hugh Dickins @ 2012-05-16 18:09 UTC (permalink / raw)
To: Lukáš Czerner
Cc: Allison Henderson, Jan Kara, Dave Chinner, Theodore Ts'o,
linux-ext4
On Tue, May 15, 2012 at 11:14 PM, Lukáš Czerner <lczerner@redhat.com> wrote:
> On Tue, 15 May 2012, Hugh Dickins wrote:
>>> Date: Tue, 15 May 2012 15:38:33 -0700 (PDT)
>> From: Hugh Dickins <hughd@google.com>
>> To: Allison Henderson <achender@linux.vnet.ibm.com>
>> Cc: Jan Kara <jack@suse.cz>, Dave Chinner <david@fromorbit.com>,
>> Theodore Ts'o <tytso@mit.edu>, linux-ext4@vger.kernel.org,
>> Lukas Czerner <lczerner@redhat.com>
>> Subject: Re: punch-hole should go beyond i_size
>>
>> On Tue, 15 May 2012, Allison Henderson wrote:
>> > On 05/13/2012 02:13 PM, Hugh Dickins wrote:
>> > > On Thu, 12 Jan 2012, Allison Henderson wrote:
>> > >> On 01/11/2012 07:55 PM, Dave Chinner wrote:
>> > >>> On Wed, Jan 11, 2012 at 05:02:12PM -0800, Hugh Dickins wrote:
>> > >>>> Hi Allison,
>> > >>>>
>> > >>>> In thinking about fallocate() on tmpfs, I cross-check with ext4
>> > >>>> and find this bug in its implementation of FALLOC_FL_PUNCH_HOLE:
>> > >>>>
>> > >>>> rm -f temp
>> > >>>> fallocate -l 4096 temp
>> > >>>> du temp # shows 4, right
>> > >>>> fallocate -p -l 4096 temp
>> > >>>> du temp # shows 0, right
>> > >>>> rm -f temp
>> > >>>> fallocate -n -l 4096 temp
>> > >>>> du temp # shows 4, right
>> > >>>> fallocate -p -l 4096 temp
>> > >>>> du temp # shows 4, wrong
>> > >>>> rm temp
>> > >>>>
>> > >>>> ext4_ext_punch_hole() contains /* No need to punch hole beyond i_size */
>> > >>>> early return, and trimming to i_size below, but forgets that the other
>> > >>>> variety of fallocate(), with FALLOC_FL_KEEP_SIZE set, may have allocated
>> > >>>> blocks beyond i_size. They can be removed with ftruncate(), but it is
>> > >>>> unexpected for fallocate() not to undo its own work, and xfs does so.
>> > >>>
>> > >>> I'm pretty sure that's a bug as XFS allows punching holes in extents
>> > >>> beyond EOF.
>> > >>>
>> > >>> Cheers,
>> > >>>
>> > >>> Dave.
>> > >>
>> > >> Oh I see, I'll take a look at it, I think it will be ok to just take out the
>> > >> early return. Thx!
>> > >
>> > > I see the -EOPNOTSUPPs have gone into 3.4's ext4_punch_hole() - thanks -
>> > > but the i_size issue remains unfixed. I wouldn't be surprised if it were
>> > > more complicated than you had hoped - I had no intention of trying a patch
>> > > myself! It's not an actual problem for me, but I thought I'd just send a
>> > > reminder, before I move out of the hole-punching business.
>> >
>> > Hi all,
>> >
>> > I had a fix for this a while ago and I believe Lukas had rebased it
>> > when he was working on some punch hole optimizations, but Im not sure
>> > what happened to it after that. I think Lukas might still be working
>> > on that set? If not, I can take a peek at it again and see if I can
>> > get it updated and resent. Thx!
>> >
>> > Allison Henderson
>>
>> Thanks, Allison. I just added Jan to the Cc list to make sure he sees,
>> since we mentioned this in the inode_dio_wait thread (which I skilfully
>> directed to an almost disjoint set of addressees - though I expect he
>> already saw via linux-ext4).
>>
>> Hugh
>
> Yes, we've been talking about this issue on LSF with Ted and the
> conclusion is that we want to wait for the range locks to be ready.
> This way we can avoid taking imutex for the punch hole when punching
> beyond isize which we would have to do otherwise.
>
> I am not sure how big of an issue this is, probably not so big. If
> we can not wait for the range locks, I can make a patch with imutex
> protection.
I agree with you, this issue is not big enough to be worth reordering
ext4 priorities and making an interim fix. I don't think it has
actually inconvenienced anyone at all, but merely came to my notice
when I was trying to work out the correct behaviour for tmpfs.
However, the issues that Jan is grappling with in "Hole punching and
mmap races" seem more serious, and may end up affecting or solving
this one too.
Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2012-05-16 18:09 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-01-12 1:02 punch-hole should go beyond i_size Hugh Dickins
2012-01-12 2:55 ` Dave Chinner
2012-01-12 16:23 ` Allison Henderson
2012-01-13 0:21 ` Hugh Dickins
2012-01-13 3:18 ` Allison Henderson
2012-05-13 21:13 ` Hugh Dickins
2012-05-15 21:36 ` Allison Henderson
2012-05-15 22:38 ` Hugh Dickins
2012-05-16 6:14 ` Lukáš Czerner
2012-05-16 18:09 ` Hugh Dickins
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).