Re: [reiserfs-list] fsync() Performance Issue
Hello! On Thu, May 02, 2002 at 07:07:18AM +0200, Christian Stuke wrote: Could we have this for 2.4.18+ pending also please? This patch would apply to 2.4.18 + pending patches, I believe. As for including these patchs into pending queue for 2.4.18, this is impossible now, it is too big of a change, unfortunatelly. We hope to get something like this into 2.4.19-pre1+ Bye, Oleg
[reiserfs-list] DNS server reading directly from reiserfs
Continuing from an earlier discussion I had regarding the use of reiserfs based files in place of databases, I was thinking about the issues involved in serving DNS data directly from files. The concern I had previously was the performance hit from open(),read(),close() to access a single piece of data to answer a query. Today I realized that DJBDNS uses the CDB format and does an open(),read(),close() sequence for each query as well. So it can't be that bad. This would come down to reiserfs vs CDB for which is the faster in finding the desired piece of data, not the syscall interfaces, in terms of comparing these two. Assuming all data is in a single directory, or maybe is in a directory tree structured TLD-first, what performance level might one expect doing this? With ext2 it could be quite costly due to the O(N) lookup. With reiserfs tree structure, this would be a lot better. And with tail-packing, less RAM would be needed to keep lots of data in cache for large servers. Any thoughts or benchmark data along these lines? -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ | -
Re: [reiserfs-list] DNS server reading directly from reiserfs
Phil Howard wrote: Continuing from an earlier discussion I had regarding the use of reiserfs based files in place of databases, I was thinking about the issues involved in serving DNS data directly from files. The concern I had previously was the performance hit from open(),read(),close() to access a single piece of data to answer a query. Today I realized that DJBDNS uses the CDB format and does an open(),read(),close() sequence for each query as well. So it can't be that bad. This would come down to reiserfs vs CDB for which is the faster in finding the desired piece of data, not the syscall interfaces, in terms of comparing these two. Assuming all data is in a single directory, or maybe is in a directory tree structured TLD-first, what performance level might one expect doing this? With ext2 it could be quite costly due to the O(N) lookup. With reiserfs tree structure, this would be a lot better. And with tail-packing, less RAM would be needed to keep lots of data in cache for large servers. Any thoughts or benchmark data along these lines? You never know until you measure. Try it! Hans
[reiserfs-list] reiserfsck aborts in pass1
i've got some problems with the filesystem, so i check the filesystem with the reiserfsck. i'm on kernel 2.4.18 . but i think, the filesystem was corrupted by an older kernel (2.4.14)... laax:~ # reiserfsck --rebuild-tree /dev/sdb1 -reiserfsck, 2002- reiserfsprogs 3.x.1b ** ** This is an experimental version of reiserfsck, ** ** !! MAKE A BACKUP FIRST !! ** ** Don't run this program unless something is broken. ** ** Some types of random FS damage can be recovered from ** ** by this program, which basically throws away ** ** the internal nodes of the tree and then reconstructs ** ** them. This program is for use only by the desperate, ** ** and is of only beta quality. If you are using the ** ** latest reiserfsprogs and it fails please email ** ** bug reports to [EMAIL PROTECTED]** ** Will rebuild the filesystem (/dev/sdb1) tree Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes):Yes Replaying journal.. 0 transactions replayed ### reiserfsck --rebuild-tree started at Thu May 2 16:02:38 2002 ### Pass 0: ### Pass 0 ### Loading on-disk bitmap .. ok, 3402700 blocks marked used Skipping 8344 blocks (super block, journal, bitmaps) 3394356 blocks will be read 0%pass0: vpf-10170: block 8787: item 12: (65535 1198 0x1 IND (1)) fixed to 1196 1198 0x1 IND (1) pass0: vpf-10170: block 8994: item 10: (2090 2095 0x1 IND (1)) fixed to 65535 2095 0x1 IND (1) pass0: vpf-10180: block 8994: item 11: 2090 2095 0x1001 DRCT (2) follows non stat item of the same file 65535 2095 0x1 IND (1) - deleted pass0: block 8994: 10-th (upper) item (65535 2095 0x1 IND (1)) is out of order, deleted pass0: block 8994: 9-th (upper) item (65535 2095 0x0 SD (0)) is out of order, deleted pass0: block 9073, item 8 2571 0x1 DIR (3), len 363, location 3501 entry count 14, fsck need 0, format old: 1 entries were deleted of pass0: block 11909, item 6393 6394 0x1 DIR (3), len 2595, location 1501 entry count 56, fsck need 0, format old: 1 entries were deleted of pass0: block 12955, item 9923 9941 0x7607f000 DIR (3), len 1443, location 2653 entry count 31, fsck need 0, format old: 1 entries were deleted of pass0: block 14670, item 13454 13519 0x1 DIR (3), len 1172, location 144 entry count 23, fsck need 0, format old: 1 entries were deleted of pass0: vpf-10170: block 16027: item 6: (13513 16600 0x1 DRCT (2)) fixed to 885601481 16600 0x1 DRCT (2) pass0: block 16027: 7-th (lower) item (13514 13515 0x0 SD (0)) is out of order, deleted pass0: block 19249, item 20475 21134 0x1 DIR (3), len 417, location 2120 entry count 8, fsck need 0, format old: 1 entries were deleted of pass0: block 19672, item 20475 20498 0x1 DIR (3), len 2208, location 754 entry count 54, fsck need 0, format old: 1 entries were deleted of pass0: block 19772, item 20479 20480 0x1 DIR (3), len 422, location 1223 entry count 7, fsck need 0, format old: 1 entries were deleted of pass0: vpf-10170: block 22033: item 2: (28759 28761 0x1 DRCT (2)) fixed to 28759 1884909657 0x1 DRCT (2) pass0: block 22033: 2-th (upper) item (28759 1884909657 0x1 DRCT (2)) is out of order, deleted pass0: block 22033: 1-th (upper) item (28759 1884909657 0x0 SD (0)) is out of order, deleted pass0: block 22408, item 30030 30384 0x1 DIR (3), len 2197, location 1815 entry count 59, fsck need 0, format old: 1 entries were deleted of pass0: vpf-10170: block 23408: item 2: (32157 33055 0x1 IND (1)) fixed to 2107473309 33055 0x1 IND (1) pass0: vpf-10180: block 23408: item 3: 32157 33055 0x1001 DRCT (2) follows non stat item of the same file 2107473309 33055 0x1 IND (1) - deleted pass0: block 23408: 3-th (lower) item (32157 33057 0x0 SD (0)) is out of order, deleted pass0: block 29185, item 42608 42631 0x14943580 DIR (3), len 3518, location 578 entry count 58, fsck need 0, format old: 1 entries were deleted of pass0: block 29785: 0-th (upper) item (3024467013 47099 0x781 DRCT (2)) is out of order, deleted pass0: block 31632, item 49682 49683 0x1 DIR (3), len 2359, location 209 entry count 51, fsck need 0, format old: 1 entries were deleted of pass0: block 31853, item 39033 49703 0x1 DIR (3), len 1237, location 213 entry count 26, fsck need 0, format old: 1 entries were deleted of pass0: vpf-10170: block 36067: item 1: (3717062029 58528 0x1 IND (1)) fixed to 56717 58528 0x1 IND (1) pass0: block 37780, item 4795 109387 0x1 DIR (3), len 68, location 3459 entry count 3, fsck need 0, format old: 1 entries were deleted of pass0: block 39368, item 4805 4806 0x1 DIR (3), len 2449, location 1647 entry count 64, fsck need 0, format old: 1 entries were deleted of pass0: vpf-10170: block 39408: item 10: (66421 66645 0x1 DRCT (2)) fixed to 66421 72680533 0x1 DRCT (2) pass0: block 39408: 10-th (upper) item (66421 72680533 0x1 DRCT (2)) is out
Re: [reiserfs-list] reiserfsck aborts in pass1
Hi, It is probably fixed in the last pre version of reiserfsprogs. Could you run debugreiserfs -p /dev/sdb1 | bzip2 -c sdb_metadata.bz2 and put the metadata somewhere for downloading. I will check how the latest fsck will work for your case. -- Thanks, Vitaly Fertman On Thursday 02 May 2002 18:30, Oliver Jehle wrote: i've got some problems with the filesystem, so i check the filesystem with the reiserfsck. i'm on kernel 2.4.18 . but i think, the filesystem was corrupted by an older kernel (2.4.14)... laax:~ # reiserfsck --rebuild-tree /dev/sdb1 -reiserfsck, 2002- reiserfsprogs 3.x.1b
[reiserfs-list] Bad Sectors during log replay, help?
I have a kernel 2.4.18 trying to mount a reiserfs filesytem with
important data on it.
I NEED to get some data off this filesystem, what can I do?
# mount -o ro -t reiserfs /dev/hda3 /mnt/tmp
reiserfs: checking transaction log (device 03:03) ...
Warning, log replay starting on readonly filesystem
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=613153,
sector=26408
end_request: I/O error, dev 03:03 (hda), sector 26408
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=613153,
sector=26416
end_request: I/O error, dev 03:03 (hda), sector 26416
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=613153,
sector=26424
end_request: I/O error, dev 03:03 (hda), sector 26424
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=613153,
sector=26432
end_request: I/O error, dev 03:03 (hda), sector 26432
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=613153,
sector=26440
end_request: I/O error, dev 03:03 (hda), sector 26440
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=613153,
sector=26448
end_request: I/O error, dev 03:03 (hda), sector 26448
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=613153,
sector=26456
end_request: I/O error, dev 03:03 (hda), sector 26456
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=613153,
sector=26464
end_request: I/O error, dev 03:03 (hda), sector 26464
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=613153,
sector=26472
end_request: I/O error, dev 03:03 (hda), sector 26472
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=613153,
sector=26480
end_request: I/O error, dev 03:03 (hda), sector 26480
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=613153,
sector=26488
end_request: I/O error, dev 03:03 (hda), sector 26488
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=613153,
sector=26496
end_request: I/O error, dev 03:03 (hda), sector 26496
is_tree_node: node level 1 does not match to the expected one 4
vs-5150: search_by_key: invalid format found in block 14806. Fsck?
vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat
data of [1 2 0x0 SD]
Using r5 hash to sort names
ReiserFS version 3.6.25
(and the mount fails)
RE: [reiserfs-list] Bad Sectors during log replay, help?
Try turning off dma using hdparm -d 0 /dev/had, then try remounting
Will Stowe
Systems Administrator
Intec Telecom Systems
5775 Peachtree-Dunwoody Road
Atlanta, GA 30342
Work:(404) 705-2867
Email: [EMAIL PROTECTED]
-Original Message-
From: Dax Kelson [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 03, 2002 12:33 AM
To: [EMAIL PROTECTED]
Subject: [reiserfs-list] Bad Sectors during log replay, help?
I have a kernel 2.4.18 trying to mount a reiserfs filesytem with
important data on it.
I NEED to get some data off this filesystem, what can I do?
# mount -o ro -t reiserfs /dev/hda3 /mnt/tmp
reiserfs: checking transaction log (device 03:03) ...
Warning, log replay starting on readonly filesystem
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=613153,
sector=26408
end_request: I/O error, dev 03:03 (hda), sector 26408
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=613153,
sector=26416
end_request: I/O error, dev 03:03 (hda), sector 26416
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=613153,
sector=26424
end_request: I/O error, dev 03:03 (hda), sector 26424
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=613153,
sector=26432
end_request: I/O error, dev 03:03 (hda), sector 26432
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=613153,
sector=26440
end_request: I/O error, dev 03:03 (hda), sector 26440
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=613153,
sector=26448
end_request: I/O error, dev 03:03 (hda), sector 26448
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=613153,
sector=26456
end_request: I/O error, dev 03:03 (hda), sector 26456
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=613153,
sector=26464
end_request: I/O error, dev 03:03 (hda), sector 26464
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=613153,
sector=26472
end_request: I/O error, dev 03:03 (hda), sector 26472
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=613153,
sector=26480
end_request: I/O error, dev 03:03 (hda), sector 26480
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=613153,
sector=26488
end_request: I/O error, dev 03:03 (hda), sector 26488
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=613153,
sector=26496
end_request: I/O error, dev 03:03 (hda), sector 26496
is_tree_node: node level 1 does not match to the expected one 4
vs-5150: search_by_key: invalid format found in block 14806. Fsck?
vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat
data of [1 2 0x0 SD]
Using r5 hash to sort names
ReiserFS version 3.6.25
(and the mount fails)
