Hi Chris,
since rc-6 seems to be the last rc for 3.0 and in case you''re already
preparing your pull request for 3.1, can you please pull the following
updates for scrub, based on your for-linus tree (2f7e33d432)?
git://git.kernel.org/pub/scm/linux/kernel/git/arne/btrfs-unstable-arne.git
for-chris
It just contains the readahead patch, which gives a significant
performance improvement for scrub. Currently scrub is the only
consumer.
Thanks,
Arne
Arne Jansen (7):
btrfs: add an extra wait mode to read_extent_buffer_pages
btrfs: add READAHEAD extent buffer flag
btrfs: state information for readahead
btrfs: initial readahead code and prototypes
btrfs: hooks for readahead
btrfs: test ioctl for readahead
btrfs: use readahead API for scrub
fs/btrfs/Makefile | 3 +-
fs/btrfs/ctree.h | 21 ++
fs/btrfs/disk-io.c | 85 +++++-
fs/btrfs/disk-io.h | 2 +
fs/btrfs/extent_io.c | 9 +-
fs/btrfs/extent_io.h | 4 +
fs/btrfs/ioctl.c | 93 +++++-
fs/btrfs/ioctl.h | 16 +
fs/btrfs/reada.c | 949
++++++++++++++++++++++++++++++++++++++++++++++++++
fs/btrfs/scrub.c | 116 +++----
fs/btrfs/volumes.c | 8 +
fs/btrfs/volumes.h | 8 +
12 files changed, 1239 insertions(+), 75 deletions(-)
create mode 100644 fs/btrfs/reada.c
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
21:00, Arne Jansen worte:> Hi Chris, > > since rc-6 seems to be the last rc for 3.0 and in case you''re already > preparing your pull request for 3.1, can you please pull the following > updates for scrub, based on your for-linus tree (2f7e33d432)? > > git://git.kernel.org/pub/scm/linux/kernel/git/arne/btrfs-unstable-arne.git > for-chris > > It just contains the readahead patch, which gives a significant > performance improvement for scrub. Currently scrub is the only > consumer. > > Thanks, > Arne > > Arne Jansen (7): > btrfs: add an extra wait mode to read_extent_buffer_pages > btrfs: add READAHEAD extent buffer flag > btrfs: state information for readahead > btrfs: initial readahead code and prototypes > btrfs: hooks for readahead > btrfs: test ioctl for readaheadDo we really want this ioctl that is merely for testing some kernel APIs in our upstream kernel?> btrfs: use readahead API for scrub > > fs/btrfs/Makefile | 3 +- > fs/btrfs/ctree.h | 21 ++ > fs/btrfs/disk-io.c | 85 +++++- > fs/btrfs/disk-io.h | 2 + > fs/btrfs/extent_io.c | 9 +- > fs/btrfs/extent_io.h | 4 + > fs/btrfs/ioctl.c | 93 +++++- > fs/btrfs/ioctl.h | 16 + > fs/btrfs/reada.c | 949 > ++++++++++++++++++++++++++++++++++++++++++++++++++ > fs/btrfs/scrub.c | 116 +++---- > fs/btrfs/volumes.c | 8 + > fs/btrfs/volumes.h | 8 + > 12 files changed, 1239 insertions(+), 75 deletions(-) > create mode 100644 fs/btrfs/reada.c-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Excerpts from Li Zefan''s message of 2011-07-05 21:06:02 -0400:> 21:00, Arne Jansen worte: > > Hi Chris, > > > > since rc-6 seems to be the last rc for 3.0 and in case you''re already > > preparing your pull request for 3.1, can you please pull the following > > updates for scrub, based on your for-linus tree (2f7e33d432)? > > > > git://git.kernel.org/pub/scm/linux/kernel/git/arne/btrfs-unstable-arne.git > > for-chris > > > > It just contains the readahead patch, which gives a significant > > performance improvement for scrub. Currently scrub is the only > > consumer. > > > > Thanks, > > Arne > > > > Arne Jansen (7): > > btrfs: add an extra wait mode to read_extent_buffer_pages > > btrfs: add READAHEAD extent buffer flag > > btrfs: state information for readahead > > btrfs: initial readahead code and prototypes > > btrfs: hooks for readahead > > btrfs: test ioctl for readahead > > Do we really want this ioctl that is merely for testing some kernel > APIs in our upstream kernel?I''d like to avoid the ioctl for now, since once it is there we''re stuck with it forever. At least for the 3.1 pull lets keep it out please. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06.07.2011 03:06, Li Zefan wrote:> 21:00, Arne Jansen worte: >> Hi Chris, >> >> since rc-6 seems to be the last rc for 3.0 and in case you''re already >> preparing your pull request for 3.1, can you please pull the following >> updates for scrub, based on your for-linus tree (2f7e33d432)? >> >> git://git.kernel.org/pub/scm/linux/kernel/git/arne/btrfs-unstable-arne.git >> for-chris >> >> It just contains the readahead patch, which gives a significant >> performance improvement for scrub. Currently scrub is the only >> consumer. >> >> Thanks, >> Arne >> >> Arne Jansen (7): >> btrfs: add an extra wait mode to read_extent_buffer_pages >> btrfs: add READAHEAD extent buffer flag >> btrfs: state information for readahead >> btrfs: initial readahead code and prototypes >> btrfs: hooks for readahead >> btrfs: test ioctl for readahead > > Do we really want this ioctl that is merely for testing some kernel > APIs in our upstream kernel?Oh, I completely forgot about that. You''re right of course. I pushed the for-chris branch again, it now looks like this: Arne Jansen (6): btrfs: add an extra wait mode to read_extent_buffer_pages btrfs: add READAHEAD extent buffer flag btrfs: state information for readahead btrfs: initial readahead code and prototypes btrfs: hooks for readahead btrfs: use readahead API for scrub fs/btrfs/Makefile | 3 +- fs/btrfs/ctree.h | 21 ++ fs/btrfs/disk-io.c | 85 +++++- fs/btrfs/disk-io.h | 2 + fs/btrfs/extent_io.c | 9 +- fs/btrfs/extent_io.h | 4 + fs/btrfs/reada.c | 949 ++++++++++++++++++++++++++++++++++++++++++++++++++ fs/btrfs/scrub.c | 116 +++---- fs/btrfs/volumes.c | 8 + fs/btrfs/volumes.h | 8 + 10 files changed, 1133 insertions(+), 72 deletions(-) create mode 100644 fs/btrfs/reada.c Thanks, Arne -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html