Tomas Szepe writes:
> > >> > This should help:
> > >> >
> > >> > diff -Nru a/txnmgr.c b/txnmgr.c
> > >> > --- a/txnmgr.c Wed Oct 30 18:58:09 2002
> > >> > +++ b/txnmgr.c Fri Nov 1 20:13:27 2002
> > >> > @@ -1917,7 +1917,7 @@
> > >> > return;
> > >> > }
> > >> >
> > >> > - if (!jnode_is_unformatted) {
> > >> > + if (jnode_is_znode(node)) {
> > >> > if ( /**jnode_get_block(node) &&*/
> > >> > !blocknr_is_fake(jnode_get_block(node))) {
> > >> > /* jnode has assigned real disk block. Put it into
> > >>
> > >>
> > >> Jup, this fixes the leak, but free space still isn't reported accurately
> > >> until after sync gets called, which I believe is a bug too.
> > >
> > >In reiser4 allocation of disk space is delayed to transaction commit. It
> > >is not possible to estimate precisely amount of disk space that will be
> > >allocated during commit, and hence statfs(2) results are not updated
> > >until one does sync(2) (forcing commit) or transaction is committed due
> > >to age (10 minutes by default).
> > >
> > The above is badly phrased, and the behavior complained of is indeed
> > a bug not a feature. Please fix.
>
> I just noticed the file
> http://thebsh.namesys.com/snapshots/2002.10.31/reiser4.diff
> had changed, the difference from the original 20021031 snapshot being:
>
> --- fs_reiser4.diff.old 2002-10-31 14:11:50.000000000 +0100
> +++ fs_reiser4.diff.new 2002-11-04 16:57:46.000000000 +0100
> @@ -46903,7 +46903,7 @@
> +#if REISER4_USER_LEVEL_SIMULATION
> +# define check_spin_is_locked(s) spin_is_locked(s)
> +# define check_spin_is_not_locked(s) spin_is_not_locked(s)
> -+#elif defined( CONFIG_DEBUG_SPINLOCK ) && defined( CONFIG_SMP )
> ++#elif 0 && defined( CONFIG_DEBUG_SPINLOCK ) && defined( CONFIG_SMP )
> +# define check_spin_is_not_locked(s) ( ( s ) -> owner != get_current() )
> +# define spin_is_not_locked(s) ( ( s ) -> owner == NULL )
> +# define check_spin_is_locked(s) ( ( s ) -> owner == get_current() )
>
> So either someone is messing about with your webserver or you want multiple
> versions of the supposedly same diff floating around (not exactly suitable
> for gathering bugreports, is it?). If you're short on disk space, how about
> gzipping the fs diff? Squeezes down to ~500k from almost 2MB.
done for 2002.10.31 snapshot.
>
> --
> Tomas Szepe <szepe@pinerecords.com>
-- Alex. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Nov 07 2002 - 22:00:37 EST