[PATCH]: reiser4 [8/8] reiser4 code

[PATCH]: reiser4 [8/8] reiser4 code

[Nikita Danilov]

Hello, Linus, hyva poika,

Reiser4 code proper is 2M. Patch is available at

http://namesys.com/snapshots/2002.10.31/fs_reiser4.diff

If you want, we can send it to you as source tar ball.

Please apply,
Nikita.

Re: [PATCH]: reiser4 [8/8] reiser4 code

[Alexander Viro]

On Thu, 31 Oct 2002, Nikita Danilov wrote:

> Hello, Linus, hyva poika,
> 
> Reiser4 code proper is 2M. Patch is available at
> 
> http://namesys.com/snapshots/2002.10.31/fs_reiser4.diff
> 
> If you want, we can send it to you as source tar ball.

And you want that to be reviewed until tonight?

Re: [PATCH]: reiser4 [8/8] reiser4 code

[Nikita Danilov]

Alexander Viro writes:
 > 
 > 
 > On Thu, 31 Oct 2002, Nikita Danilov wrote:
 > 
 > > Hello, Linus, hyva poika,
 > > 
 > > Reiser4 code proper is 2M. Patch is available at
 > > 
 > > http://namesys.com/snapshots/2002.10.31/fs_reiser4.diff
 > > 
 > > If you want, we can send it to you as source tar ball.
 > 
 > And you want that to be reviewed until tonight?
 > 

No. But changes to the core are not very complicated. If Linus "reviews"
and accepts them life of reiser4 would be much simpler.

Nikita.

Re: [PATCH]: reiser4 [8/8] reiser4 code

[Alexander Viro]

On Thu, 31 Oct 2002, Nikita Danilov wrote:

>  > And you want that to be reviewed until tonight?
>  > 
> 
> No. But changes to the core are not very complicated. If Linus "reviews"
> and accepts them life of reiser4 would be much simpler.

Changes to the core consist (AFAICS) of exporting a bunch of functions
with no explanation of the way they are used - with some of them it's
really straightforward (and can go in at any point), with some one
would expect really detailed explanation and code review (your comments
regarding fsync_super() export trigger all sorts of alarms for me).

PS: Cc'ing a posting on a public list to a subscribers-only one is
generally not a nice thing to do...  Cc: trimmed.

Re: [PATCH]: reiser4 [8/8] reiser4 code

[Nikita Danilov]

Alexander Viro writes:
 > 
 > 
 > On Thu, 31 Oct 2002, Nikita Danilov wrote:
 > 
 > >  > And you want that to be reviewed until tonight?
 > >  > 
 > > 
 > > No. But changes to the core are not very complicated. If Linus "reviews"
 > > and accepts them life of reiser4 would be much simpler.
 > 
 > Changes to the core consist (AFAICS) of exporting a bunch of functions
 > with no explanation of the way they are used - with some of them it's
 > really straightforward (and can go in at any point), with some one
 > would expect really detailed explanation and code review (your comments
 > regarding fsync_super() export trigger all sorts of alarms for me).

Let's start from fsync_super() then.

Reiser4 has data journalling.

When ->writepage() is called on dirtied page, page joins transaction.
During umount all out-standing transaction have to be committed.  But if
file were mmapped, then, at the moment of the call to ->kill_super()
pages can be dirtied without ->writepage() ever called on them.

generic_shutdown_super() calls fsync_super(sb) (which will call
->writepage() on each dirty page) and then invalidate_inodes().

Reiser4 has commit out-standing transactions -between- these two points:
after ->writepage() has been called on all dirty pages, but before
inodes were destroyed. Thus, we cannot use
kill_block_super()/generic_shutdown_super().

 > 
 > PS: Cc'ing a posting on a public list to a subscribers-only one is
 > generally not a nice thing to do...  Cc: trimmed.

Arghh... Sorry, it will be fixed... soon.

 > 

Nikita.

Re: [PATCH]: reiser4 [8/8] reiser4 code

[Alexander Viro]

On Thu, 31 Oct 2002, Nikita Danilov wrote:

> generic_shutdown_super() calls fsync_super(sb) (which will call
> ->writepage() on each dirty page) and then invalidate_inodes().
> 
> Reiser4 has commit out-standing transactions -between- these two points:
> after ->writepage() has been called on all dirty pages, but before
> inodes were destroyed. Thus, we cannot use
> kill_block_super()/generic_shutdown_super().

Why don't you do that from within fsync_super()?  That would be much
more natural point for such stuff...

I hadn't looked into akpm's stuff in fs-writeback.c for a while, but
if one can't stick such flush point in there I'd argue that this is
a bug that needs to be fixed - either there or by providing explicit
callback from fsync_super().

Note that sync(2) doesn't get anywhere near your ->kill_sb() code,
so you want fsync_super() do the right thing anyway - regardless of the
umount(2) situation.

Re: [PATCH]: reiser4 [8/8] reiser4 code

[Nikita Danilov]

[Reiserfs-List@Namesys.COM is no longer subscribers-only, back into CC]

Alexander Viro writes:
 > 
 > 
 > On Thu, 31 Oct 2002, Nikita Danilov wrote:
 > 
 > > generic_shutdown_super() calls fsync_super(sb) (which will call
 > > ->writepage() on each dirty page) and then invalidate_inodes().
 > > 
 > > Reiser4 has commit out-standing transactions -between- these two points:
 > > after ->writepage() has been called on all dirty pages, but before
 > > inodes were destroyed. Thus, we cannot use
 > > kill_block_super()/generic_shutdown_super().
 > 
 > Why don't you do that from within fsync_super()?  That would be much
 > more natural point for such stuff...
 > 
 > I hadn't looked into akpm's stuff in fs-writeback.c for a while, but
 > if one can't stick such flush point in there I'd argue that this is
 > a bug that needs to be fixed - either there or by providing explicit

->writepages gets (in wbc->sync_mode) enough information to tell
synchronization request like umount or sync from
balance_dirty_pages(). Yes, it looks like better solution,
->writepages(inode, WB_SYNC_ALL) should just synchronously commit all
transactions involving any of inode's pages.

 > callback from fsync_super().

Hmm, I just noted that for now we probably could simply use exported
fsync_bdev(s->s_bdev) in fsync_super(s) stead. How simple. Thank you for
the useful discussion. :-)

Nikita.