Re: RESVSP problems

Re: RESVSP problems

[Łukasz Fibinger]

>>> You've probably hit:
>>> http://oss.sgi.com/bugzilla/show_bug.cgi?id=418
>>> unwritten extents remain unwritten after mmap() modifies them
>>>
>>> Bug dchinner about it... ;-)
>> 
>> Dave, consider it a bugging from my humble self :-)

> Yeah, yeah ;)

> I'm waiting to see what happens with Nick's patches in .22 before
> going any further. If they are not merged into .22, then I think we
> should push the XFS specific fix in....

I wonder, what's the status of it, Dave?

Cheers,

Luke

Re: RESVSP problems

[David Chinner]

On Thu, May 24, 2007 at 01:24:52PM +0200, Å?ukasz Fibinger wrote:
> >>> You've probably hit:
> >>> http://oss.sgi.com/bugzilla/show_bug.cgi?id=418
> >>> unwritten extents remain unwritten after mmap() modifies them
> >>>
> >>> Bug dchinner about it... ;-)
> >> 
> >> Dave, consider it a bugging from my humble self :-)
> 
> > Yeah, yeah ;)
> 
> > I'm waiting to see what happens with Nick's patches in .22 before
> > going any further. If they are not merged into .22, then I think we
> > should push the XFS specific fix in....
> 
> I wonder, what's the status of it, Dave?

A couple of days ago:

http://marc.info/?l=linux-mm&m=117988295814519&w=2

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: RESVSP problems

[Łukasz Fibinger]

On Friday 25 of May 2007, you wrote:
> On Thu, May 24, 2007 at 01:24:52PM +0200, Å?ukasz Fibinger wrote:
> > >>> You've probably hit:
> > >>> http://oss.sgi.com/bugzilla/show_bug.cgi?id=418
> > >>> unwritten extents remain unwritten after mmap() modifies them
> > >>>
> > >>> Bug dchinner about it... ;-)
> > >>
> > >> Dave, consider it a bugging from my humble self :-)
> > >
> > > Yeah, yeah ;)
> > >
> > > I'm waiting to see what happens with Nick's patches in .22 before
> > > going any further. If they are not merged into .22, then I think we
> > > should push the XFS specific fix in....
> >
> > I wonder, what's the status of it, Dave?
>
> A couple of days ago:
>
> http://marc.info/?l=linux-mm&m=117988295814519&w=2
>

I see. If that's the case, would sharing your 2.6.21 XFS specific fixes (you 
have them, right?) with me be any problem for you?

Cheers,

Luke

Re: RESVSP problems

[David Chinner]

On Fri, May 25, 2007 at 12:24:23PM +0200, Å?ukasz Fibinger wrote:
> On Friday 25 of May 2007, you wrote:
> > On Thu, May 24, 2007 at 01:24:52PM +0200, Å?ukasz Fibinger wrote:
> > > >>> You've probably hit:
> > > >>> http://oss.sgi.com/bugzilla/show_bug.cgi?id=418
> > > >>> unwritten extents remain unwritten after mmap() modifies them
> > > >>>
> > > >>> Bug dchinner about it... ;-)
> > > >>
> > > >> Dave, consider it a bugging from my humble self :-)
> > > >
> > > > Yeah, yeah ;)
> > > >
> > > > I'm waiting to see what happens with Nick's patches in .22 before
> > > > going any further. If they are not merged into .22, then I think we
> > > > should push the XFS specific fix in....
> > >
> > > I wonder, what's the status of it, Dave?
> >
> > A couple of days ago:
> >
> > http://marc.info/?l=linux-mm&m=117988295814519&w=2
> >
> 
> I see. If that's the case, would sharing your 2.6.21 XFS specific fixes (you 
> have them, right?) with me be any problem for you?

The original XFS specific code was here:

http://marc.info/?l=linux-fsdevel&m=117080251026985&w=2

But if you want to patch your own kernel, I suggest that
you use the latest generic version I posted here:

http://marc.info/?l=linux-fsdevel&m=117426058311029&w=2
http://marc.info/?l=linux-fsdevel&m=117426070111133&w=2

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: RESVSP problems

[Łukasz Fibinger]

On Friday 25 of May 2007, David Chinner wrote:
> On Fri, May 25, 2007 at 12:24:23PM +0200, Å?ukasz Fibinger wrote:
> > I see. If that's the case, would sharing your 2.6.21 XFS specific fixes
> > (you have them, right?) with me be any problem for you?
>
> The original XFS specific code was here:
>
> http://marc.info/?l=linux-fsdevel&m=117080251026985&w=2
>
> But if you want to patch your own kernel, I suggest that
> you use the latest generic version I posted here:
>
> http://marc.info/?l=linux-fsdevel&m=117426058311029&w=2
> http://marc.info/?l=linux-fsdevel&m=117426070111133&w=2
>

Seems to be working as expected. Thanks.

Cheers,

Luke

Re: RESVSP problems

[Christoph Hellwig]

On Fri, May 25, 2007 at 09:24:41PM +1000, David Chinner wrote:
> The original XFS specific code was here:
> 
> http://marc.info/?l=linux-fsdevel&m=117080251026985&w=2

Btw, I think you should just push it for now.  We can convert XFS to
the generic code once ->fault goes in whenever that may be.

Re: RESVSP problems

[David Chinner]

On Fri, May 25, 2007 at 03:19:56PM +0100, Christoph Hellwig wrote:
> On Fri, May 25, 2007 at 09:24:41PM +1000, David Chinner wrote:
> > The original XFS specific code was here:
> > 
> > http://marc.info/?l=linux-fsdevel&m=117080251026985&w=2
> 
> Btw, I think you should just push it for now.  We can convert XFS to
> the generic code once ->fault goes in whenever that may be.

Ok - That original code had a coupl eof problems, so I'll fix
it up first...

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

RESVSP problems

[Łukasz Fibinger]

Hello, guys,

I've been trying to implement RESVSP-based allocation in rtorrent. From the 
very beginning it has, alas, misbehaved, thus (also considering my very basic 
programming skills and experience and unfamiliarity with rtorrent's code) 
after hours of trying to determine what's wrong, I finally observed that 
blocks of files allocated with RESVSP (previously ftruncated to a proper 
size) and being downloaded in rtorrent don't have their unwritten flags 
removed (as confirmed by xfs_bmap -vp). In the effect downloaded file 
promptly corrupts (read: changes its md5sum). What is interesting, files 
RESVSP-allocated in ktorrent and then imported to rtorrent seem to download 
properly.

Everything works properly with ALLOCSP (although I've noticed that while 
RESVSP worked with l_start = 0 and l_length = size, ALLOCSP worked with 
l_start = size and l_length = 0; is that intended?).

I'm not quite sure what's at fault here. Perhaps rtorrent, as it prides itself 
on "directly between file pages mapped to memory by the mmap() function and 
the network stack". I haven't been yet able to determine how it actually 
writes chunks to files (aforementioned lacks of skills, experience and 
familiarity). Perhaps it's somehow XFS's fault, hence my posting to this ML. 
Any help/suggestions would be appreciated.

Cheers,

Luke

Re: RESVSP problems

[Eric Sandeen]

Łukasz Fibinger wrote:
> Hello, guys,
> 
> I've been trying to implement RESVSP-based allocation in rtorrent. From the 
> very beginning it has, alas, misbehaved, thus (also considering my very basic 
> programming skills and experience and unfamiliarity with rtorrent's code) 
> after hours of trying to determine what's wrong, I finally observed that 
> blocks of files allocated with RESVSP (previously ftruncated to a proper 
> size) and being downloaded in rtorrent don't have their unwritten flags 
> removed (as confirmed by xfs_bmap -vp).

You've probably hit:
http://oss.sgi.com/bugzilla/show_bug.cgi?id=418
unwritten extents remain unwritten after mmap() modifies them

Bug dchinner about it... ;-)

> In the effect downloaded file 
> promptly corrupts (read: changes its md5sum). What is interesting, files 
> RESVSP-allocated in ktorrent and then imported to rtorrent seem to download 
> properly.
> 
> Everything works properly with ALLOCSP (although I've noticed that while 
> RESVSP worked with l_start = 0 and l_length = size, ALLOCSP worked with 
> l_start = size and l_length = 0; is that intended?).

yeah... ISTR that the arguments are funky.  I can't remember if it's a
bug or not.  :)  FWIW, allocsp just writes zeros to the file, so you
could do it just as well from userspace w/ no fancy ioctls...  ALLOCSP
is a bit pointless if you ask me... though maybe someone knows why it's
there :)

-Eric

> I'm not quite sure what's at fault here. Perhaps rtorrent, as it prides itself 
> on "directly between file pages mapped to memory by the mmap() function and 
> the network stack". I haven't been yet able to determine how it actually 
> writes chunks to files (aforementioned lacks of skills, experience and 
> familiarity). Perhaps it's somehow XFS's fault, hence my posting to this ML. 
> Any help/suggestions would be appreciated.
> 
> Cheers,
> 
> Luke
> 
> 

Re: RESVSP problems

[Łukasz Fibinger]

On Monday 07 of May 2007, you wrote:
> You've probably hit:
> http://oss.sgi.com/bugzilla/show_bug.cgi?id=418
> unwritten extents remain unwritten after mmap() modifies them
>
> Bug dchinner about it... ;-)

Dave, consider it a bugging from my humble self :-)

> yeah... ISTR that the arguments are funky.  I can't remember if it's a
> bug or not.  :)  FWIW, allocsp just writes zeros to the file, so you
> could do it just as well from userspace w/ no fancy ioctls...  ALLOCSP
> is a bit pointless if you ask me... though maybe someone knows why it's
> there :)

Let me say that I have noticed that using ALLOCSP seems to create less extents 
than posix_fallocate/manual zeroing.

Thanks for your answer. Incidentally, I'm really happy that XFS has been 
bestowed upon linux users. Thanks for all your work, guys :-)

Cheers,

Luke

Re: RESVSP problems

[David Chinner]

On Mon, May 07, 2007 at 08:58:32PM +0200, Å?ukasz Fibinger wrote:
> On Monday 07 of May 2007, you wrote:
> > You've probably hit:
> > http://oss.sgi.com/bugzilla/show_bug.cgi?id=418
> > unwritten extents remain unwritten after mmap() modifies them
> >
> > Bug dchinner about it... ;-)
> 
> Dave, consider it a bugging from my humble self :-)

Yeah, yeah ;)

I'm waiting to see what happens with Nick's patches in .22 before
going any further. If they are not merged into .22, then I think we
should push the XFS specific fix in....

> > yeah... ISTR that the arguments are funky.  I can't remember if it's a
> > bug or not.  :)  FWIW, allocsp just writes zeros to the file, so you
> > could do it just as well from userspace w/ no fancy ioctls...  ALLOCSP
> > is a bit pointless if you ask me... though maybe someone knows why it's
> > there :)
> 
> Let me say that I have noticed that using ALLOCSP seems to create less extents 
> than posix_fallocate/manual zeroing.

Yes, that's likely ;)

There's work currently active to make posix_fallocate() do the same thing
as ALLOCSP (i.e. call into the filesystem and let it do smart stuff), but
that's a ways off yet...

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: RESVSP problems

[Eric Sandeen]

David Chinner wrote:

>>> yeah... ISTR that the arguments are funky.  I can't remember if it's a
>>> bug or not.  :)  FWIW, allocsp just writes zeros to the file, so you
>>> could do it just as well from userspace w/ no fancy ioctls...  ALLOCSP
>>> is a bit pointless if you ask me... though maybe someone knows why it's
>>> there :)
>> Let me say that I have noticed that using ALLOCSP seems to create less extents 
>> than posix_fallocate/manual zeroing.
> 
> Yes, that's likely ;)
> 
> There's work currently active to make posix_fallocate() do the same thing
> as ALLOCSP (i.e. call into the filesystem and let it do smart stuff), but
> that's a ways off yet...

Dave, doesn't ALLOCSP actually create actual zeroed space though? 
Pretty much as posix_fallocate from userspace does today, maybe with 
better allocation... And "smart stuff" would be *not* needing to write 
zeros.... i.e. what RESVSP does.

-Eric

Re: RESVSP problems

[David Chinner]

On Tue, May 08, 2007 at 12:03:07AM -0500, Eric Sandeen wrote:
> David Chinner wrote:
> 
> >>>yeah... ISTR that the arguments are funky.  I can't remember if it's a
> >>>bug or not.  :)  FWIW, allocsp just writes zeros to the file, so you
> >>>could do it just as well from userspace w/ no fancy ioctls...  ALLOCSP
> >>>is a bit pointless if you ask me... though maybe someone knows why it's
> >>>there :)
> >>Let me say that I have noticed that using ALLOCSP seems to create less 
> >>extents than posix_fallocate/manual zeroing.
> >
> >Yes, that's likely ;)
> >
> >There's work currently active to make posix_fallocate() do the same thing
> >as ALLOCSP (i.e. call into the filesystem and let it do smart stuff), but
> >that's a ways off yet...
> 
> Dave, doesn't ALLOCSP actually create actual zeroed space though? 

Ah, yes it does - I was sort of lumping allocsp/resvsp together as one
there.

> Pretty much as posix_fallocate from userspace does today, maybe with 
> better allocation...

Better allocations and with no ENOSPC-after-partial-zeroing problems,
either.

> And "smart stuff" would be *not* needing to write 
> zeros.... i.e. what RESVSP does.

Yup. I've implemented fallocate() with the equivalent of RESVSP.
xfs_zero_eof() is smart enough to not try to zero unwritten extents
so changing the filesize after preallocation is effectively a no-op ;)

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group