Re: [PATCH] updated data=ordered patch for 2.6.3
Am Mittwoch, 3. März 2004 10:13 schrieb Marc-Christian Petersen: > On Tuesday 02 March 2004 20:53, Dieter Nützel wrote: > > Hi Dieter, > > > > > > I'll try on SuSE 2.6.3-16. > > sorry for my ignorance, but where do you find 2.6.3-_16_? I only find -0 ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/suse/people/kraxel Or the "original site" and its mirrors. Regards, Dieter
Re: [PATCH] updated data=ordered patch for 2.6.3
Am Montag, 1. März 2004 15:38 schrieb Chris Mason: > On Mon, 2004-03-01 at 09:30, Christophe Saout wrote: > > Am Mo, den 01.03.2004 schrieb Chris Mason um 15:01: > > > > It seems you introduced a bug here. I installed the patches yesterday > > > > and found a lockup on my notebook when running lilo (with /boot on > > > > the root reiserfs filesystem). > > > > > > > > A SysRq-T showed that lilo is stuck in fsync: > > > > > > Ugh, I use grub so I haven't tried lilo. Could you please send me the > > > full sysrq-t, this is probably something stupid. > > > > Yes. I could reproduce it by simply creating a dummy /boot volume on > > reiserfs. I copied the content of /boot, ran lilo and it hung again. The > > other reiserfs filesystems were still usable (but a global sync hangs > > afterwards). I also attached a bzipped strace of the lilo process. > > Ok, thanks. The problem is in reiserfs_unpack(), which needs updating > for the patch. Fixing. I'll test this under SuSE 2.6.3-7 (with lilo). Or is it in? Thanks, Dieter
Re: [PATCH] updated data=ordered patch for 2.6.3
On Mon, 2004-03-01 at 09:30, Christophe Saout wrote: > Am Mo, den 01.03.2004 schrieb Chris Mason um 15:01: > > > > It seems you introduced a bug here. I installed the patches yesterday > > > and found a lockup on my notebook when running lilo (with /boot on the > > > root reiserfs filesystem). > > > > > > A SysRq-T showed that lilo is stuck in fsync: > > > > Ugh, I use grub so I haven't tried lilo. Could you please send me the > > full sysrq-t, this is probably something stupid. > > Yes. I could reproduce it by simply creating a dummy /boot volume on > reiserfs. I copied the content of /boot, ran lilo and it hung again. The > other reiserfs filesystems were still usable (but a global sync hangs > afterwards). I also attached a bzipped strace of the lilo process. > Ok, thanks. The problem is in reiserfs_unpack(), which needs updating for the patch. Fixing. -chris
Re: [PATCH] updated data=ordered patch for 2.6.3
On Mon, 2004-03-01 at 08:30, Christophe Saout wrote: > Hi, > > > Also, the code has some extra performance tweaks to smooth out > > performance both with and without data=ordered. There are new > > mechanisms to trigger metadata/commit block writeback and to help > > throttle writers. The goal is to reduce the huge bursts of io during a > > commit and during data=ordered writeback. > > It seems you introduced a bug here. I installed the patches yesterday > and found a lockup on my notebook when running lilo (with /boot on the > root reiserfs filesystem). > > A SysRq-T showed that lilo is stuck in fsync: > Ugh, I use grub so I haven't tried lilo. Could you please send me the full sysrq-t, this is probably something stupid. -chris
Re: [PATCH] updated data=ordered patch for 2.6.3
Hi, > Also, the code has some extra performance tweaks to smooth out > performance both with and without data=ordered. There are new > mechanisms to trigger metadata/commit block writeback and to help > throttle writers. The goal is to reduce the huge bursts of io during a > commit and during data=ordered writeback. It seems you introduced a bug here. I installed the patches yesterday and found a lockup on my notebook when running lilo (with /boot on the root reiserfs filesystem). A SysRq-T showed that lilo is stuck in fsync: lilo: schedule sleep_on default_wake_function sys_sched_yield let_transaction_grow __commit_trans_jl reiserfs_sync_file sys_fsync reiserfs/0: worker_thread flush_async_commits default_wake_function ... The problem is 100% reproducable here. Perhaps it has something to do with tail unpacking? This is strange: After copying the bzImage file to /boot and running lilo he can add the copied bzImage file, add the old file and then hangs on the third one. But after rebooting and running lilo he already hangs on the first one. After copying the file again he again passes the first two and hangs on the third kernel to add. The whole filesystem locks up when this happens, not just the lilo process.
[PATCH] updated data=ordered patch for 2.6.3
Hello everyone, I've updated the reiserfs logging speedups and data=ordered support to 2.6.3, and fixed a few bugs: i_block count not properly updated on files with holes oops when the disk is full small files were not being packed into tails Also, the code has some extra performance tweaks to smooth out performance both with and without data=ordered. There are new mechanisms to trigger metadata/commit block writeback and to help throttle writers. The goal is to reduce the huge bursts of io during a commit and during data=ordered writeback. I'm very interested in benchmarks here and info about how the patches feel for interactive performance. Please note that data=ordered is not the default yet, you have to mount with -o data=ordered to get it. You can get the patches from: ftp.suse.com/pub/people/mason/patches/data-logging/experimental/2.6.3 (once the suse mirror copies it over there) -chris
