Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[patch 0/7] per-bdi flushing model improvements. reiser4

1 view
Skip to first unread message

Edward Shishkin

unread,
Feb 1, 2010, 8:50:01 PM2/1/10
to
Hello.

Andrew Morton wrote:
> reiser4 is currently disabled in -mm (via reiser4-disable.patch)
> because recent changes to fs/fs/writeback.c wrecked the build. I fixed
> it about ten times as the underlying code was churning, then gave up. It
> would be nice if you take a look at that sometime please.
>
>

I have taken a look at fs/fs-writeback.c and found that per-superblock
flushing interface is eliminated. However migrating to per-bdi flushing
model doesn't necessarily means that such interface doesn't exist or is
not needed anymore. Flushing in accordance with the scheme "data-inode-
data-inode-..." would be very suboptimal for reiser4. Also xfs people
were unhappy with such flushing model:
http://article.gmane.org/gmane.linux.file-systems/30153

Moreover, the current stuff looks rather ugly. Why do we pin/unpin
superblock for every inode? It would be more reasonable to pin it for the
whole group of inodes and call a flushing handler for them. The patch 4
introduces such handler writeback_sb_inodes (which resembles dropped
sync_sb_inodes, the difference is that the newer version doesn't flush
necessarily all inodes of the superblock). Please, consider pushing this
patch to mainline.

The patch 5 adds super operation .writeback_inodes (former .sync_inodes)
which allows a file system to make optimizations. It can happen that
reiser4 will flush a bit more inodes then generic implementation suggests.
"a bit more" doesn't mean "all dirty inodes of the superblock" (see a
comment about atoms in the header of patch 6).

Finally, some file systems have its own means for periodical writeout
of dirty data. Since b_io contains inodes of many superblocks we need
to evict our inodes back to dirty list when flushing is going on with
for_kupdate flag installed. The new library function
writeback_skip_sb_inodes() provides such possibility.

Patch 7 fixes a race in checkin-checkout jnodes for entd task (reiser4).
Please, apply.

Thanks,
Edward.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Edward Shishkin

unread,
Feb 1, 2010, 9:00:02 PM2/1/10
to
Hello.

Andrew Morton wrote:
> reiser4 is currently disabled in -mm (via reiser4-disable.patch)
> because recent changes to fs/fs/writeback.c wrecked the build. I fixed
> it about ten times as the underlying code was churning, then gave up. It
> would be nice if you take a look at that sometime please.
>
>

I have taken a look at fs/fs-writeback.c and found that per-superblock
flushing interface is eliminated. However migrating to per-bdi flushing
model doesn't necessarily means that such interface doesn't exist or is
not needed anymore. Flushing in accordance with the scheme "data-inode-
data-inode-..." would be very suboptimal for reiser4. Also xfs people
were unhappy with such flushing model:
http://article.gmane.org/gmane.linux.file-systems/30153

Moreover, current stuff doesn't look fine. Why do we pin/unpin


superblock for every inode? It would be more reasonable to pin it for the
whole group of inodes and call a flushing handler for them. The patch 4
introduces such handler writeback_sb_inodes (which resembles dropped
sync_sb_inodes, the difference is that the newer version doesn't flush
necessarily all inodes of the superblock). Please, consider pushing this
patch to mainline.

The patch 5 adds a super operation .writeback_inodes (former .sync_inodes)


which allows a file system to make optimizations. It can happen that
reiser4 will flush a bit more inodes then generic implementation suggests.
"a bit more" doesn't mean "all dirty inodes of the superblock" (see a
comment about atoms in the header of patch 6).

Finally, some file systems have its own means for periodical writeout
of dirty data. Since b_io contains inodes of many superblocks we need
to evict our inodes back to dirty list when flushing is going on with
for_kupdate flag installed. The new library function
writeback_skip_sb_inodes() provides such possibility.

Please, apply.

Christoph Hellwig

unread,
Feb 2, 2010, 3:20:01 AM2/2/10
to
I got this introduction twice, but patches 1-3 didn't make it to any of
the lists.

Edward Shishkin

unread,
Feb 2, 2010, 10:30:02 AM2/2/10
to
Christoph Hellwig wrote:
> I got this introduction twice, but patches 1-3 didn't make it to any of
> the lists.
>
>
>
done

Jens Axboe

unread,
Feb 2, 2010, 2:50:02 PM2/2/10
to
On Tue, Feb 02 2010, Edward Shishkin wrote:
> Christoph Hellwig wrote:
>> I got this introduction twice, but patches 1-3 didn't make it to any of
>> the lists.
>>
>>
>>
> done

Where?

--
Jens Axboe

Ronni Holm-Nielsen

unread,
Feb 2, 2010, 4:50:02 PM2/2/10
to
On Tue, Feb 2, 2010 at 11:42 PM, Jens Axboe <jens....@oracle.com> wrote:
>
> On Tue, Feb 02 2010, Edward Shishkin wrote:
> > Christoph Hellwig wrote:
> >> I got this introduction twice, but patches 1-3 didn't make it to any of
> >> the lists.
> Where?

To clarify (being a ReiserFS subscriber):
patch 0, 4-6 sent to Andrew, ReiserFS, linux-fsdevel, linux-kernel,
xfs, jens.axboe
patch 1-3, 7 sent to Andrew, ReiserFS

- Ronni

Edward Shishkin

unread,
Feb 2, 2010, 5:30:02 PM2/2/10
to
Hello everyone.

The patches 1-3 are reverses for the following -mm stuff:

http://userweb.kernel.org/~akpm/mmotm/broken-out/reiser4-fixed-null-pointer-dereference.patch
http://userweb.kernel.org/~akpm/mmotm/broken-out/reiser4-generic_sync_sb_inodes-doesnt-exist-anymore.patch
http://userweb.kernel.org/~akpm/mmotm/broken-out/reiser4-vfs-add-super_operationssync_inodes-2.patch

This is incorrect attempts to adjust reiser4 to the new per-bdi flushing
model.
The authors are cc-ed,
any comments, suggestions are welcome.

Thanks,
Edward.


Ronni Holm-Nielsen wrote:
> To clarify (being a ReiserFS subscriber):
>
> patch 0, 4-6 sent to Andrew, ReiserFS, linux-fsdevel, linux-kernel, xfs,
> jens.axboe
> patch 1-3, 7 sent to Andrew, ReiserFS
>
> - Ronni
>

> On Tue, Feb 2, 2010 at 11:42 PM, Jens Axboe <jens....@oracle.com> wrote:
>
>

>> On Tue, Feb 02 2010, Edward Shishkin wrote:
>>
>>> Christoph Hellwig wrote:
>>>
>>>> I got this introduction twice, but patches 1-3 didn't make it to any of
>>>> the lists.
>>>>
>>>>
>>>>
>>>>
>>> done
>>>
>> Where?
>>
>> --
>> Jens Axboe
>>
>> --

>> To unsubscribe from this list: send the line "unsubscribe reiserfs-devel"

Johannes Buchner

unread,
Feb 21, 2010, 2:50:01 PM2/21/10
to
Hi.

Thank you Edward. The related bug was/is
http://bugzilla.kernel.org/show_bug.cgi?id=14915
It'd be great if someone could solve this, as the reiser4 patch is
not usable in its current state, with or without my illfated attempts
to fix it.

Kind regards,
Johannes


--
Emails können geändert, gefälscht und eingesehen werden. Signiere oder
verschüssele deine Mails mit GPG.
http://web.student.tuwien.ac.at/~e0625457/pgp.html

Edward Shishkin

unread,
Feb 21, 2010, 3:10:02 PM2/21/10
to
Hello.

Everything should work now (at least it works for me).
Please check the latest -mm or reiser4-for-2.6.32 stuff
If no problems then let's close this BZ..

Thanks,
Edward.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in


the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Christian Kujau

unread,
Feb 24, 2010, 2:20:02 AM2/24/10
to
On Mon, 22 Feb 2010 at 08:47, Johannes Buchner wrote:
> It'd be great if someone could solve this, as the reiser4 patch is
> not usable in its current state, with or without my illfated attempts
> to fix it.

FWIW, I'm running Linus' latest -git with refs/heads/reiser4 on top[0], no
issues during 2.6.33-git so far. Try it, if you don't like
manually applying patches either :-)

Christian.

[0] http://git.zen-kernel.org/?p=kernel/zen.git;a=shortlog;h=refs/heads/reiser4
--
BOFH excuse #275:

Bit rot
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in


the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

0 new messages