RESVSP problems
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
Quoted 9 lines · Ł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).
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... ;-)
Quoted 8 lines
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 andl_length= size, ALLOCSP worked withl_start= size andl_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
Quoted 12 lines
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
Quoted 5 lines · you
You've probably hit:
http://oss.sgi.com/bugzilla/show_bug.cgi?id=418
unwritten extents remain unwritten aftermmap()modifies themBug dchinner about it... ;-)
Dave, consider it a bugging from my humble self :-)
Quoted 5 lines
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
Quoted 8 lines · Å?ukasz Fibinger
Quoted 5 lines · you
You've probably hit:
http://oss.sgi.com/bugzilla/show_bug.cgi?id=418
unwritten extents remain unwritten aftermmap()modifies themBug 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....
Quoted 8 lines
Quoted 5 lines
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.
Signature · 3 lines
Dave Chinner Principal Engineer SGI Australian Software Group
Quoted 5 lines · David Chinner
Quoted 5 lines
Quoted 5 lines
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 :)
Quoted 7 lines
Quoted 1 line
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
Quoted 10 lines · Eric Sandeen
Quoted 8 lines · David Chinner
Quoted 7 lines
Quoted 5 lines
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.
Quoted 7 lines
Quoted 5 lines
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.
Quoted 2 lines
Pretty much as
posix_fallocatefrom userspace does today, maybe with better allocation...
Better allocations and with no ENOSPC-after-partial-zeroing problems, either.
Quoted 2 lines
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.
Signature · 3 lines
Dave Chinner Principal Engineer SGI Australian Software Group