From: Eric Sandeen <sandeen@sandeen.net>
To: lucke@o2.pl
Cc: xfs@oss.sgi.com
Subject: Re: RESVSP problems
Date: Mon, 07 May 2007 13:43:52 -0500 [thread overview]
Message-ID: <463F7368.8090101@sandeen.net> (raw)
In-Reply-To: <200705072004.22848.lucke@o2.pl>
Ł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
>
>
next prev parent reply other threads:[~2007-05-07 18:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-07 18:04 RESVSP problems Łukasz Fibinger
2007-05-07 18:43 ` Eric Sandeen [this message]
2007-05-07 18:58 ` Łukasz Fibinger
2007-05-08 0:59 ` David Chinner
2007-05-08 5:03 ` Eric Sandeen
2007-05-08 5:25 ` David Chinner
-- strict thread matches above, loose matches on Subject: below --
2007-05-24 11:24 Łukasz Fibinger
2007-05-25 5:06 ` David Chinner
2007-05-25 10:24 ` Łukasz Fibinger
2007-05-25 11:24 ` David Chinner
2007-05-25 13:37 ` Łukasz Fibinger
2007-05-25 14:19 ` Christoph Hellwig
2007-05-28 0:50 ` David Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=463F7368.8090101@sandeen.net \
--to=sandeen@sandeen.net \
--cc=lucke@o2.pl \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.