Hi all -
I'd like to submit my reiserfs patch queue for inclusion into 2.6.30. I've
received a bunch of requests from Christoph asking me to do this over the
past two years. They needed some cleaning up (done), and there was one final
crash that prevented me from submitting to 2.6.27 and 2.6.28, which has now
been fixed. These patches have been in several openSUSE releases and, outside
of the now-fixed crash, they've been stable. Once this is applied, I expect
reiserfs to be in deep maintenance-only mode.
There are 35 patches in several groups:
- Quick fixes
- Implement mount count and expiry in the superblock.
- Audit commit id's to always be unsigned ints
- Better error handling and reporting
- Standardizes error output
- Adds more robust error handling where it will currently panic
- Extended attribute rework
- Cleans up the code
- Improves locking
- Journals extended attributes
- Adds selinux support
- Uses generic xattr helpers
- Code cleanups
- Simplifies the buffer_info struct usage
- Kills off decrement_bcount and cleans up surrounding code
- Strips whitespace
- Kills off the stupid variable name prefixing
Please apply.
-Jeff
--
Jeff Mahoney
SUSE Labs
On Mon, 30 Mar 2009, Jeff Mahoney wrote:
>
> I'd like to submit my reiserfs patch queue for inclusion into 2.6.30.
Hmm. Looks fine, and I merged it. I had a number of mostly trivial
conflicts (most due to the quota name cleanup to lower-case, with some
header file export cleanup conflicts added in), but they looked fairly
straightforward and I compile-tested the end result.
I don't have any reiserfs filesystems left, though, so you should really
double-check the end result.
> Once this is applied, I expect reiserfs to be in deep maintenance-only
> mode.
Heh, I hadn't expected even this.
Linus
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Linus Torvalds wrote:
>
> On Mon, 30 Mar 2009, Jeff Mahoney wrote:
>> I'd like to submit my reiserfs patch queue for inclusion into 2.6.30.
>
> Hmm. Looks fine, and I merged it. I had a number of mostly trivial
> conflicts (most due to the quota name cleanup to lower-case, with some
> header file export cleanup conflicts added in), but they looked fairly
> straightforward and I compile-tested the end result.
>
> I don't have any reiserfs filesystems left, though, so you should really
> double-check the end result.
Great, thanks! I realized just after I submitted that I didn't adjust
context to the last few days of mainline. The merge looks good except
for an added space in reiserfs_delete_inode. I've appended the patch for that.
>> Once this is applied, I expect reiserfs to be in deep maintenance-only
>> mode.
>
> Heh, I hadn't expected even this.
Hopefully it won't be. I still have to support reiserfs for our
enterprise releases, though. :)
- -Jeff
- ---
fs/reiserfs/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
- --- a/fs/reiserfs/inode.c
+++ b/fs/reiserfs/inode.c
@@ -52,7 +52,7 @@ void reiserfs_delete_inode(struct inode
/* Do quota update inside a transaction for journaled quotas. We must do that
* after delete_object so that quota updates go into the same transaction as
* stat data deletion */
- - if (!err)
+ if (!err)
vfs_dq_free_inode(inode);
if (journal_end(&th, inode->i_sb, jbegin_count))
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iEYEARECAAYFAknRJLQACgkQLPWxlyuTD7IuOgCbBmWsC7seMVyE7TLD2gejcHgz
c9EAn2Ey64m2xNZ8R53lWqvAiWlX4UcP
=Ugl0
-----END PGP SIGNATURE-----
* Linus Torvalds <[email protected]> wrote:
> > Once this is applied, I expect reiserfs to be in deep
> > maintenance-only mode.
>
> Heh, I hadn't expected even this.
Note, there are BKL-removal patches in the works by Fr?d?ric
Weisbecker, for the tip:kill-the-BKL topic branch.
Reiser3 is the heaviest (and most non-trivial) BKL user amongst all
the filesystems, its BKL use is recursive and it frequently relies
on the implicit dropping of the BKL at various blocking points both
for correctness and for performance reasons.
There might be something worth posting+reviewing soon.
Ingo
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ingo Molnar wrote:
> * Linus Torvalds <[email protected]> wrote:
>
>>> Once this is applied, I expect reiserfs to be in deep
>>> maintenance-only mode.
>> Heh, I hadn't expected even this.
>
> Note, there are BKL-removal patches in the works by Fr?d?ric
> Weisbecker, for the tip:kill-the-BKL topic branch.
>
> Reiser3 is the heaviest (and most non-trivial) BKL user amongst all
> the filesystems, its BKL use is recursive and it frequently relies
> on the implicit dropping of the BKL at various blocking points both
> for correctness and for performance reasons.
>
> There might be something worth posting+reviewing soon.
Oh interesting. I'm glad someone is working on this. I've started to
several times and decided to focus my efforts on things outside of
reiserfs instead. The reiserfs usage of the BKL has always been a black
mark.
- -Jeff
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iEYEARECAAYFAknTlkIACgkQLPWxlyuTD7IAsQCfSNKuHk7oL8KhZK1InW7b189z
K4kAn3lINkZFMg89wJbwSiLZEfeQLLJA
=grqX
-----END PGP SIGNATURE-----
* Jeff Mahoney <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ingo Molnar wrote:
> > * Linus Torvalds <[email protected]> wrote:
> >
> >>> Once this is applied, I expect reiserfs to be in deep
> >>> maintenance-only mode.
> >> Heh, I hadn't expected even this.
> >
> > Note, there are BKL-removal patches in the works by Fr?d?ric
> > Weisbecker, for the tip:kill-the-BKL topic branch.
> >
> > Reiser3 is the heaviest (and most non-trivial) BKL user amongst all
> > the filesystems, its BKL use is recursive and it frequently relies
> > on the implicit dropping of the BKL at various blocking points both
> > for correctness and for performance reasons.
> >
> > There might be something worth posting+reviewing soon.
>
> Oh interesting. I'm glad someone is working on this. I've started
> to several times and decided to focus my efforts on things outside
> of reiserfs instead. The reiserfs usage of the BKL has always been
> a black mark.
I'll let Frederic describe it but AFAIK the patch is working fine
with the BKL as a mutex and no lockdep complaints or lockups. The
main focus is now on finding the performance affecting spots,
because Frederic's main desktop is on reiserfs and he does not
accept a slowdown :)
Ingo
On Wed, Apr 01, 2009 at 06:34:07PM +0200, Ingo Molnar wrote:
>
> * Jeff Mahoney <[email protected]> wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Ingo Molnar wrote:
> > > * Linus Torvalds <[email protected]> wrote:
> > >
> > >>> Once this is applied, I expect reiserfs to be in deep
> > >>> maintenance-only mode.
> > >> Heh, I hadn't expected even this.
> > >
> > > Note, there are BKL-removal patches in the works by Fr?d?ric
> > > Weisbecker, for the tip:kill-the-BKL topic branch.
> > >
> > > Reiser3 is the heaviest (and most non-trivial) BKL user amongst all
> > > the filesystems, its BKL use is recursive and it frequently relies
> > > on the implicit dropping of the BKL at various blocking points both
> > > for correctness and for performance reasons.
> > >
> > > There might be something worth posting+reviewing soon.
> >
> > Oh interesting. I'm glad someone is working on this. I've started
> > to several times and decided to focus my efforts on things outside
> > of reiserfs instead. The reiserfs usage of the BKL has always been
> > a black mark.
>
> I'll let Frederic describe it but AFAIK the patch is working fine
> with the BKL as a mutex and no lockdep complaints or lockups. The
> main focus is now on finding the performance affecting spots,
> because Frederic's main desktop is on reiserfs and he does not
> accept a slowdown :)
Hehe :-)
No actually I would accept a tiny slowdown but I fear that the common
reiserfs users wouldn't.
I'm still working on this and once it's ready enough for an RFC patch,
I'll explain how is done the conversion to a mutex.
Stay tuned.
> Ingo
On Wed, Apr 01, 2009 at 06:51:36PM +0200, Frederic Weisbecker wrote:
> > I'll let Frederic describe it but AFAIK the patch is working fine
> > with the BKL as a mutex and no lockdep complaints or lockups. The
> > main focus is now on finding the performance affecting spots,
> > because Frederic's main desktop is on reiserfs and he does not
> > accept a slowdown :)
>
> Hehe :-)
> No actually I would accept a tiny slowdown but I fear that the common
> reiserfs users wouldn't.
We run big(ish) imap servers with up to 80 reiserfs partitions
spread over a bunch of SCSI or SAS attached external drive units.
I'm actually surprised that the BKL isn't causing us much pain
(load is amazingly low considering how many users are on these
boxes - at least now that we have 32Gb RAM and 64 bit kernels).
Are you still using an "entire reiserfs subsystem" mutex, or
per-filesystem locking? If it's per filesystem, then I suspect
we'll be big fans!
> I'm still working on this and once it's ready enough for an RFC patch,
> I'll explain how is done the conversion to a mutex.
>
> Stay tuned.
Sure will!
Thanks,
Bron.
On Thu, Apr 02, 2009 at 09:18:50AM +1100, Bron Gondwana wrote:
> On Wed, Apr 01, 2009 at 06:51:36PM +0200, Frederic Weisbecker wrote:
> > > I'll let Frederic describe it but AFAIK the patch is working fine
> > > with the BKL as a mutex and no lockdep complaints or lockups. The
> > > main focus is now on finding the performance affecting spots,
> > > because Frederic's main desktop is on reiserfs and he does not
> > > accept a slowdown :)
> >
> > Hehe :-)
> > No actually I would accept a tiny slowdown but I fear that the common
> > reiserfs users wouldn't.
>
> We run big(ish) imap servers with up to 80 reiserfs partitions
> spread over a bunch of SCSI or SAS attached external drive units.
> I'm actually surprised that the BKL isn't causing us much pain
> (load is amazingly low considering how many users are on these
> boxes - at least now that we have 32Gb RAM and 64 bit kernels).
>
> Are you still using an "entire reiserfs subsystem" mutex, or
> per-filesystem locking? If it's per filesystem, then I suspect
> we'll be big fans!
Yeah. It is per superblock :-)
Frederic.
>
> > I'm still working on this and once it's ready enough for an RFC patch,
> > I'll explain how is done the conversion to a mutex.
> >
> > Stay tuned.
>
> Sure will!
>
> Thanks,
>
> Bron.