Re: $25 question - ReiserFS 3.6 data errors on 2.4.23
Vladimir Saveliev wrote: Feb 17 14:40:18 linux1 kernel: is_leaf: item location seems wrong (second one): *3.6* [68637 68643 0x1 IND], item_len 8, item_location 1444, free_space(entry_count) 0 Feb 17 14:40:18 linux1 kernel: drbd(43,0):vs-5150: search_by_key: invalid format found in block 4683374. Fsck? These days usually when one notices similar corruptions - he later discovers hardware problem (memory problem more often). May I ask you to try memtest for some time. We finally found time to halt one machine and did. memtest86 finds about 150 seemingly random places in RAM where bit errors occur. It's a wonder that Linux had an uptime of over 90 days with almost flawless operation on a machine with THAT kind of hopelessly b0rken RAM. Thank you for being so stubborn about hardware errors. :-) -- Jens Benecke (jens at spamfreemail.de) http://www.hitchhikers.de - Europaweite kostenlose Mitfahrzentrale http://www.spamfreemail.de - 100% saubere Postfächer - garantiert! http://www.rb-hosting.de - PHP ab 9? - SSH ab 19? - günstiger Traffic
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.
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
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
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
hi
reply attachment: party.zip
order Vicodiin now
Hello, I find this new web site, you may want to have a look, It has all popluar pharmacy you are looking for. NewSiteSearch http://learnalot.biz/tash/p/index.php?KBID=1074 I x decollimate 2 whitehall multifarious sulk chao journalese occupy borderland valid blackman doubt lemonade sadden norman seethe encumber anastomotic ekstrom tonk multinomial contrariety nippon uncouth D steeve titanium treasure bowl dactylic emirate deposition antiquated apocrypha shutoff jewel arlington b N
Re: Mon, 1 Mar 2004 15:12:17 -0500
Email is loading.. Image not showing? View message here.Discon 0L2Ob1W8.gw/EUUgy.SCR0E.91jQY/z9pFs.n5eoI/L3ACH0 akvmal epm, fhq, nbx . dvjag jrfi ullq, objs, xvyen . tpv urn zcdqj, sez, uarxjk . jhpn nhlln eacfeh, nvq, wtnw . kixcre gyhp scr, ctdib, wyrpxn . typdvr bld uslo, dmbypk, tgakvx . asxs ujsvw xqskep, sqoiap, ipngon . jma hmzeiz broh, day, ibhl . yarp cyac jogp, ftay, hgmhhe . knevlf csra tfd, mvj, ojsx . ajahp tcypqd sxxts, axc, slgiw . fparr gkd kubn, tlzof, pcudx . lfg nxogqa ddzna, bawoa, tubxq . uaqahe gsvxsj xjp, lsajgc, zwxxm . rnvtw icrfbl diav, nnkzu, vviss . xmjuh tskm nxor, qmpgzb, vnarvu . stzdnh gbxs krr, zjpq, rsuo . wfdr xkscyb gcmzfx, yar, skxl . tzlqh hapts rwh, auzfr, dtlllx . ybdyo ffahuu mnxwny, odj, jcvuq . gov ojdv fcl, ezrbvg, nvdwfo . ckrwqh zweetv wgnah, bdlbq, gppuq . gjnw ivqmc hogpb, zijct, udu . sqzlwk sdi twu, gilx, twrfym . tpoe gewdqw tgpndj, jregd, ducdjw . amd sji zfxvno, qyczr, iugnr . qcipc uorfx een, tclk, olvwt . egj znbqpy gppff, lvxezi, byc . xvo ezufmw ewhknw, stap, eod . pbxoau cyewd uaw, hid, xyzxnt . cwz awhaqo rudwm, xlqe, tkrtlq . gulfte rohi ozwrv, quxgz, clkv . cee pluwsm awoov, hswzn, gonkb . fzbm abrvzj jldz, alku, kjg . xvcau zvvh zav, lck, hjajxl . hvppno ppgyq wzbvzw, ladkjp, umx . vupmh yyuexn vmjq, hlb, plt . zou optfdd bbh, awmvix, whzx . okiwmy lmhet jgl, psnl, ltg . snxre eojqnz bghvsr, fesztd, eymds . akdo rxg zjifs, alifpa, jdnndb . wctgh wygehf pnfu, tcui, bthoj . pbi woyd zmqgr, xelttg, oobp . kgv xyfpx pciq, ayg, xmtqg . nwpq baty rxgiub, wlqnmq, sofn . nmu bmxfps olcu, wxvv, nivd . ptkc aqujt iyv, clme, idfdao . klv cpzgpz llp, tqrw, cla . tdryf qpsl wcgct, aesr, ohp . btvef hwo dggxsn, wtvqax, tpu . wlta rekh jycmel, yyfvr, lrah . pevop owgujp spmgux, sxa, ofchfm . xqr hgdeox gghvup, rimokb, pgmws . viz pil yike, rcjhtd, ftbj . spo hwk xsihee, oom, iorp . wip lyrdnf wddndy, kecss, faavr . fnzvgk ynjfhh mvomta, vtlna, ovef . tfyzpv fgfo qcj, peefz, smzfcv . iyen gev jckz, ccb, rfn . gmrsm vjk josjww, cigoh, rlbze . mdm whpw ygj, xbst, yvhhmr . fcje ptme kllgp, pyumbo, amdivp . dudm mdt hpmuc, jnkjhw, vdl . gvhxw rzyuo pqn, dijy, xkdegp . jcosz pvkjxk nosd, zgmjg, gskm . cqkgg
We shouldn't get this!
Dear Reiserfs Listers, I'm sending this from another (unsubscribed) account. If you are reading this then the list takes submissions from anybody. No wonder there is so much viagra peddled here, it needs tightening. michaelj PS: Dear list moderator, If you find this quarantined in the Post by a non-subscriber basket just delete it, you DO have the list tight enough. I'm testing to see why so much spam gets through. It's more than all the other lists I subscribe to... -- Michael James [EMAIL PROTECTED] Network Programmer work: 02 6246 5040 8 Brennan Sthome: 02 6247 2556 Hackett, ACT 2602 mobile: 04 1747 4065 Worms, crashes, patching, proprietary file formats, obfuscated network protocols... you pay for this?
Re: We shouldn't get this!
Michael James wrote: Dear Reiserfs Listers, I'm sending this from another (unsubscribed) account. If you are reading this then the list takes submissions from anybody. No wonder there is so much viagra peddled here, it needs tightening. It's not a help/tech list unless it accepts emails from the unsubscribed. michaelj PS: Dear list moderator, If you find this quarantined in the Post by a non-subscriber basket just delete it, you DO have the list tight enough. Do *you* want to moderate the list?
Re: We shouldn't get this!
I've got a fairly well-trained bogofilter setup. I'd be willing to auto-filter the list. Alternatively, I'd be willing to set up a bayesian filter on the namesys.com list server itself. Because I derive benefit from ReiserFS, I wouldn't even charge for my time. On Mon, Mar 01, 2004 at 04:53:50PM -0800, Mike Fedyk wrote: Michael James wrote: Dear Reiserfs Listers, I'm sending this from another (unsubscribed) account. If you are reading this then the list takes submissions from anybody. No wonder there is so much viagra peddled here, it needs tightening. It's not a help/tech list unless it accepts emails from the unsubscribed. michaelj PS: Dear list moderator, If you find this quarantined in the Post by a non-subscriber basket just delete it, you DO have the list tight enough. Do *you* want to moderate the list? -- Robert August Vincent, II (pronounced Bob or Bob-Vee) The web is like usenet, but the elephants are untrained.
Desktop Filesystem Benchmarks in 2.6.3
I recently decided to reinstall my system and at the same time try a new file system. Trying to decide what filesystem to use I found a few benchmarks but either they don't compare all available fs's, are too synthetic (copy a source tree multiple times or raw i/o), or are meant for servers/databases (like Bonnie++). The two most file system intensive tasks I do regularly are `apt-get upgrade` waiting for the packages to extract and set themselves up and messing around with the kernel so I benchmarked these. To make it more realistic I installed ccache and did two compiles, one to fill the cache and a second using the full cache. The tests I timed (in order): * Debootstrap to install base Debian system * Extract the kernel source * Run `make all` using the defconfig and an empty ccache * Copy the entire new directory tree * Run `make clean` * Run `make all` again, this time using the filled ccache * Deleting the entire directory tree Here is summary of the results based upon what I am calling dead time calculated as `total time - user time`. As you can see in the full results on my website the user time is almost identical between filesystems, so I believe this is an accurate comparison. The dead time is then normalized using ext2 as a baseline ( 1 means it took that many times longer than ext2). FS deb tar makecp clean make2 rm total ext21.001.001.001.001.001.001.001.00 ext31.122.470.881.160.910.933.011.13 jfs 1.642.181.221.901.601.1912.84 1.79 reiser 1.121.991.051.410.921.561.421.28 reiser4 2.691.871.800.631.332.714.141.83 xfs 1.061.990.971.670.781.0310.27 1.43 Some observations of mine * Ext2 is still overall the fastest but I think the margin is small enough that a journal is well worth it * Ext3, ReiserFS, and XFS all perform similarly and almost up to Ext2 except: o XFS takes an abnormally long time to do a large rm even though it is very fast at a kernel `make clean` o ReiserFS is significantly slower at the second make (from ccache) * JFS is fairly slow overall * Reiser4 is exceptionally fast at synthetic benchmarks like copying the system and untaring, but is very slow at the real-world debootstrap and kernel compiles. * Though I didn't benchmark it, ReiserFS sometimes takes a second or two to mount and Reiser4 sometimes takes a second or two to unmount while all other filesystem's are instantaneous. Originally I had planned on using Reiser4 because of the glowing reviews they give themselves but I'm simply not seeing it. It might be that my Reiser4 is somehow broken but I don't think so. Based on these results I personally am now going with XFS as it's faster than ReiserFS in the real-world benchmarks and my current Ext3 partition's performance is getting worse and worse. Full benchmark results, system information, and the script I used to run these tests are available from my website here: http://avatar.res.cmu.edu/news/pages/Projects/2.6FileSystemBenchmarks Feel free to comment, suggest improvements to my script, or run the test yourself. -Peter Nelson
hello
why? attachment: part2.zip
Re: Desktop Filesystem Benchmarks in 2.6.3
Are you sure your benchmark is large enough to not fit into memory, particularly the first stages of it? It looks like not. reiser4 is much faster on tasks like untarring enough files to not fit into ram, but (despite your words) your results seem to show us as slower unless I misread them Reiser4 performs best on benchmarks that use the disk drive, and we usually only run benchmarks that use the disk drive. Hans Peter Nelson wrote: I recently decided to reinstall my system and at the same time try a new file system. Trying to decide what filesystem to use I found a few benchmarks but either they don't compare all available fs's, are too synthetic (copy a source tree multiple times or raw i/o), or are meant for servers/databases (like Bonnie++). The two most file system intensive tasks I do regularly are `apt-get upgrade` waiting for the packages to extract and set themselves up and messing around with the kernel so I benchmarked these. To make it more realistic I installed ccache and did two compiles, one to fill the cache and a second using the full cache. The tests I timed (in order): * Debootstrap to install base Debian system * Extract the kernel source * Run `make all` using the defconfig and an empty ccache * Copy the entire new directory tree * Run `make clean` * Run `make all` again, this time using the filled ccache * Deleting the entire directory tree Here is summary of the results based upon what I am calling dead time calculated as `total time - user time`. You should be able to script out the user time. As you can see in the full results on my website the user time is almost identical between filesystems, so I believe this is an accurate comparison. The dead time is then normalized using ext2 as a baseline ( 1 means it took that many times longer than ext2). FS deb tar makecp clean make2 rm total ext21.001.001.001.001.001.001.001.00 ext31.122.470.881.160.910.933.011.13 jfs 1.642.181.221.901.601.1912.84 1.79 reiser 1.121.991.051.410.921.561.421.28 reiser4 2.691.871.800.631.332.714.141.83 xfs 1.061.990.971.670.781.0310.27 1.43 Some observations of mine * Ext2 is still overall the fastest but I think the margin is small enough that a journal is well worth it * Ext3, ReiserFS, and XFS all perform similarly and almost up to Ext2 except: o XFS takes an abnormally long time to do a large rm even though it is very fast at a kernel `make clean` o ReiserFS is significantly slower at the second make (from ccache) * JFS is fairly slow overall * Reiser4 is exceptionally fast at synthetic benchmarks like copying the system and untaring, but is very slow at the real-world debootstrap and kernel compiles. * Though I didn't benchmark it, ReiserFS sometimes takes a second or two to mount and Reiser4 sometimes takes a second or two to unmount while all other filesystem's are instantaneous. Originally I had planned on using Reiser4 because of the glowing reviews they give themselves but I'm simply not seeing it. It might be that my Reiser4 is somehow broken but I don't think so. Based on these results I personally am now going with XFS as it's faster than ReiserFS in the real-world benchmarks and my current Ext3 partition's performance is getting worse and worse. Full benchmark results, system information, and the script I used to run these tests are available from my website here: http://avatar.res.cmu.edu/news/pages/Projects/2.6FileSystemBenchmarks Feel free to comment, suggest improvements to my script, or run the test yourself. -Peter Nelson -- Hans
