From kenneth.m.guyton at emory.edu Thu Jun 1 17:39:55 2006 From: kenneth.m.guyton at emory.edu (Ken Guyton) Date: Thu, 01 Jun 2006 13:39:55 -0400 Subject: Errors on EXT3 on RHEL3, Can we use e2fsprogs 1.36? Message-ID: <447F266B.8090908@emory.edu> SUMMARY We are getting many ``Free blocks count wrong for group'' errors when running e2fsck on a 245-GB ext3 filesystem. This is when the file system is cleanly unmounted on a relatively quiet system to do a resize. From reading other messages here, my suspicion is that this is because we have e2fsprogs 1.32. Questions: * Should we use e2fsck/e2fsprogs 1.36 and will that probably address this problem? * Is e2fsprogs 1.36 compatible with EXT3 2.4-0.9.19 on RHEL3? DETAILS Kernel: Linux ****** 2.4.21-37.0.1.ELsmp #1 SMP Wed Jan 11 18:44:17 EST 2006 i686 i686 i386 GNU/Linux FS: EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,1), internal journal ---------------------------------------------------------------------- dumpe2fs 1.32 (09-Nov-2002) ... Filesystem revision #: 1 (dynamic) Filesystem features: has_journal dir_index filetype needs_recovery sparse_super ---------------------------------------------------------------------- As far as I can tell every group is enumerated in the e2fsck output (see below). We've unmounted, run e2fsck and extended the filesystem several times and we saw these errors every time. Each time we ran e2fsck on the fs. This filesystem stores email for the Cyrus IMAP software. However, user trees of sometimes large Berkeley mbox files are copied to this filesystem, converted to Cyrus message files, then deleted. So large collections of large files are created and deleted in a rather short period of time. The mounted device is an LVM logical volume and the back end storage is EMC. Thanks. Ken Guyton Emory University Output of e2fsck: ---------------------------------------------------------------------- e2fsck 1.32 (09-Nov-2002) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 3A: Optimizing directories Optimizing directories: 163843 196610 491522 589826 688143 720898... Pass 4: Checking reference counts Pass 5: Checking group summary information Block bitmap differences: -(12--1033) -(32780--33801) -(65537--65546)... Fix? yes Free blocks count wrong for group #0 (6582, counted=7604). Fix? yes Free blocks count wrong for group #1 (14316, counted=15338). Fix? yes Free blocks count wrong for group #2 (30603, counted=30613). Fix? yes ... Free blocks count wrong for group #1006 (13, counted=23). Fix? yes Free blocks count wrong for group #1007 (0, counted=10). Fix? yes Free blocks count wrong for group #1008 (0, counted=10). Fix? yes Free blocks count wrong for group #1009 (0, counted=10). Fix? yes Free blocks count wrong (3497725, counted=3523005). Fix? yes y /dev/mailvg/mailvol: ***** FILE SYSTEM WAS MODIFIED ***** /dev/mailvg/mailvol: 2461667/39714816 files (2.1% non-contiguous), 36191811/39714816 blocks ---------------------------------------------------------------------- From evilninja at gmx.net Sat Jun 3 12:05:56 2006 From: evilninja at gmx.net (christian) Date: Sat, 3 Jun 2006 13:05:56 +0100 (BST) Subject: Errors on EXT3 on RHEL3, Can we use e2fsprogs 1.36? In-Reply-To: <447F266B.8090908@emory.edu> References: <447F266B.8090908@emory.edu> Message-ID: Hi Ken, On Thu, 1 Jun 2006, Ken Guyton wrote: > * Should we use e2fsck/e2fsprogs 1.36 and will that probably address this > problem? That'd be a good idea, given the old version you're using atm. > * Is e2fsprogs 1.36 compatible with EXT3 2.4-0.9.19 on RHEL3? yes. Are you running fsck on a (ro-)mounted fs? If yes and the errors persist, please try to unmount the fs. Christian. -- BOFH excuse #38: secretary plugged hairdryer into UPS From kenneth.m.guyton at emory.edu Wed Jun 7 20:06:04 2006 From: kenneth.m.guyton at emory.edu (Ken Guyton) Date: Wed, 07 Jun 2006 16:06:04 -0400 Subject: Errors on EXT3 on RHEL3, Can we use e2fsprogs 1.36? Message-ID: <448731AC.1060708@emory.edu> > Are you running fsck on a (ro-)mounted fs? If yes and the errors persist, > please try to unmount the fs. No, we've always unmounted the fs before trying fsck. Thanks! Ken Guyton From tytso at mit.edu Thu Jun 8 13:50:27 2006 From: tytso at mit.edu (Theodore Tso) Date: Thu, 8 Jun 2006 09:50:27 -0400 Subject: Errors on EXT3 on RHEL3, Can we use e2fsprogs 1.36? In-Reply-To: <447F266B.8090908@emory.edu> References: <447F266B.8090908@emory.edu> Message-ID: <20060608135027.GC5134@thunk.org> On Thu, Jun 01, 2006 at 01:39:55PM -0400, Ken Guyton wrote: > SUMMARY > > We are getting many ``Free blocks count wrong for group'' errors when > running e2fsck on a 245-GB ext3 filesystem. This is when the file > system is cleanly unmounted on a relatively quiet system to do a > resize. From reading other messages here, my suspicion is that this > is because we have e2fsprogs 1.32. I'm not certain that the problem is caused by e2fsprogs 1.32, but it is a very old version of e2fsprogs. In general though e2fsprogs is quite careful about backwards compatibility, so it should be safe to use the latest e2fsprogs 1.39 on an RHEL3 system. You will have to compile it yourself from source, though. (And there have been quite a lot of bugs fixed between 1.36 and 1.39) - Ted From billlin at wshlab2.ee.kuas.edu.tw Mon Jun 12 11:48:59 2006 From: billlin at wshlab2.ee.kuas.edu.tw (Ching-Hung Lin) Date: Mon, 12 Jun 2006 19:48:59 +0800 Subject: Some questions about function usage Message-ID: <20060612114842.M62680@wshlab2.ee.kuas.edu.tw> Hello, Recently, I am coding a program about read and write control. And there are some questions confusing me. 1. In info libext2fs: Function: errcode_t ext2fs_get_blocks (ext2_filsys FS, ext2_ino_t INO, blk_t *BLOCKS) Returns an array of blocks corresponding to the direct, indirect, doubly indirect, and triply indirect blocks as stored in the inode structure. So I wrote some codes like following: blk_t target_blks[EXT_N_BLOCKS]; retval = ext2fs_get_blocks(fs, ino, target_blks); printf("[percentage]u [percentage]u [percentage]u", *target_blks, target_blks[1], target_blks[2]); P.S. [percentage] is "shift+5" The output of printf is strange. *target_blks is the actul block number of the first block of target inode. But target_blks[1] and target_blks[2] always 0(zero). Why and how I get the correct an array of blocks? 2. I get a "Attempt to write block from filesystem resulted in short write" when I calling io_channel_write_byte( ). Why? My code: unsigned char write_buf[4096]; retval = io_channel_write_byte(fs->io, 100581, -4096, write_buf); if (retval) { com_err (program_name, retval, "while callng io_channel_write_byte"); printf ("Failure: Calling function io_channel_write_byte.\n"); exit (1); } 3. I can using io_channel_write_blk to write data in the desired block. But the changed content of block must readed by io_channel_read_blk( ). (for example: 'a' is overwrite by 'b', and the editor still read 'a', but io_channel_read_blk read 'b); But I do have call io_channel_flush(fs->io) before ext2fs_close(fs). Is there anything more I should do(like sync or something else)? Finally, please let me know if this letter shouldn't appears in this mailing list. Thank you for reading such boring and stupid letter. Thanks for any reply message. Ching-Hung Lin ??? ?? Ching-Hung Lin, CNPAL, EE, KUAS, R.O.C.(Twiwan) 07-3814526#5566 From niam.tni at googlemail.com Tue Jun 20 16:35:49 2006 From: niam.tni at googlemail.com (Stefan Drexleri) Date: Tue, 20 Jun 2006 18:35:49 +0200 Subject: viewing ext3 journal Message-ID: <35ce7f5b0606200935p655a35a9i8b4d02dc571535dd@mail.gmail.com> Hi! Is there a way to view ext3 filesystem's maintained journal (in a human-readable-format)? I ask, because i have had a server crash before and now i'm wondering if i might take a look at last things that my server did straight before crash. I guess clarifying log insertions might be lost before buffers were flushed to disk. Thx. From adilger at clusterfs.com Tue Jun 20 18:17:42 2006 From: adilger at clusterfs.com (Andreas Dilger) Date: Tue, 20 Jun 2006 12:17:42 -0600 Subject: viewing ext3 journal In-Reply-To: <35ce7f5b0606200935p655a35a9i8b4d02dc571535dd@mail.gmail.com> References: <35ce7f5b0606200935p655a35a9i8b4d02dc571535dd@mail.gmail.com> Message-ID: <20060620181742.GV5817@schatzie.adilger.int> On Jun 20, 2006 18:35 +0200, Stefan Drexleri wrote: > Is there a way to view ext3 filesystem's maintained journal (in a > human-readable-format)? > I ask, because i have had a server crash before and now i'm wondering > if i might take a look at last things that my server did straight > before crash. I guess clarifying log insertions might be lost before > buffers were flushed to disk. With "debugfs -c -R 'dump <8> /tmp/journal'" you can dump the journal contents to a file, but that doesn't make it human readable... Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. From niam.tni at googlemail.com Tue Jun 20 19:57:34 2006 From: niam.tni at googlemail.com (Stefan Drexleri) Date: Tue, 20 Jun 2006 21:57:34 +0200 Subject: viewing ext3 journal In-Reply-To: <20060620181742.GV5817@schatzie.adilger.int> References: <35ce7f5b0606200935p655a35a9i8b4d02dc571535dd@mail.gmail.com> <20060620181742.GV5817@schatzie.adilger.int> Message-ID: <35ce7f5b0606201257k816293aub8dc1120bcd61a35@mail.gmail.com> 2006/6/20, Andreas Dilger : > > With "debugfs -c -R 'dump <8> /tmp/journal'" you can dump the journal > contents to a file, but that doesn't make it human readable... > Hi, i get error message "dump: filesystem not open". What does <8> mean? I tried out to specifiy device file, but same error message. From adilger at clusterfs.com Tue Jun 20 22:14:47 2006 From: adilger at clusterfs.com (Andreas Dilger) Date: Tue, 20 Jun 2006 16:14:47 -0600 Subject: viewing ext3 journal In-Reply-To: <35ce7f5b0606201257k816293aub8dc1120bcd61a35@mail.gmail.com> References: <35ce7f5b0606200935p655a35a9i8b4d02dc571535dd@mail.gmail.com> <20060620181742.GV5817@schatzie.adilger.int> <35ce7f5b0606201257k816293aub8dc1120bcd61a35@mail.gmail.com> Message-ID: <20060620221447.GY5817@schatzie.adilger.int> On Jun 20, 2006 21:57 +0200, Stefan Drexleri wrote: > 2006/6/20, Andreas Dilger : > >With "debugfs -c -R 'dump <8> /tmp/journal'" you can dump the journal > >contents to a file, but that doesn't make it human readable... > > i get error message "dump: filesystem not open". > What does <8> mean? I tried out to specifiy device file, but same error > message. Sorry, you need to add your device name to the end of the above command, like "debugfs -c -R 'dump <8> /tmp/journal' /dev/hda1" or whatever. It will dump the journal inode (#8) to the file /tmp/journal. But that is just a raw block dump, you would need to hack debugfs to do something more clever to dump the logical structure of the journal (e.g. which transactions are present, blocks modified in each transaction, etc). Doing that would be useful and would likely get accepted into e2fsprogs pretty easily. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. From niam.tni at googlemail.com Tue Jun 20 22:46:21 2006 From: niam.tni at googlemail.com (Stefan Drexleri) Date: Wed, 21 Jun 2006 00:46:21 +0200 Subject: viewing ext3 journal In-Reply-To: <20060620221447.GY5817@schatzie.adilger.int> References: <35ce7f5b0606200935p655a35a9i8b4d02dc571535dd@mail.gmail.com> <20060620181742.GV5817@schatzie.adilger.int> <35ce7f5b0606201257k816293aub8dc1120bcd61a35@mail.gmail.com> <20060620221447.GY5817@schatzie.adilger.int> Message-ID: <35ce7f5b0606201546n3e88102fk44ff871ac30206f3@mail.gmail.com> 2006/6/21, Andreas Dilger : > > Sorry, you need to add your device name to the end of the above command, > like "debugfs -c -R 'dump <8> /tmp/journal' /dev/hda1" or whatever. It > will dump the journal inode (#8) to the file /tmp/journal. But that is > just a raw block dump, you would need to hack debugfs to do something > more clever to dump the logical structure of the journal (e.g. which > transactions are present, blocks modified in each transaction, etc). > Oh i see raw data ;) What a shame! The Possibility to view last filesystem actions in a human readable format would have been nice. Thank you! From adilger at clusterfs.com Wed Jun 21 04:35:10 2006 From: adilger at clusterfs.com (Andreas Dilger) Date: Tue, 20 Jun 2006 22:35:10 -0600 Subject: viewing ext3 journal In-Reply-To: <35ce7f5b0606201546n3e88102fk44ff871ac30206f3@mail.gmail.com> References: <35ce7f5b0606200935p655a35a9i8b4d02dc571535dd@mail.gmail.com> <20060620181742.GV5817@schatzie.adilger.int> <35ce7f5b0606201257k816293aub8dc1120bcd61a35@mail.gmail.com> <20060620221447.GY5817@schatzie.adilger.int> <35ce7f5b0606201546n3e88102fk44ff871ac30206f3@mail.gmail.com> Message-ID: <20060621043510.GA5817@schatzie.adilger.int> On Jun 21, 2006 00:46 +0200, Stefan Drexleri wrote: > 2006/6/21, Andreas Dilger : > >Sorry, you need to add your device name to the end of the above command, > >like "debugfs -c -R 'dump <8> /tmp/journal' /dev/hda1" or whatever. It > >will dump the journal inode (#8) to the file /tmp/journal. But that is > >just a raw block dump, you would need to hack debugfs to do something > >more clever to dump the logical structure of the journal (e.g. which > >transactions are present, blocks modified in each transaction, etc). > > Oh i see raw data ;) > What a shame! The Possibility to view last filesystem actions in a > human readable format would have been nice. Note that this would never be possible (or at least very easy) with ext3 journaling since ext3 uses "block journaling", where the whole filesystem block that is modified is written to the journal (e.g. one or two directory leaf blocks and up to four inode table blocks are written to disk for a rename). This is different than e.g. XFS which uses "logical journaling" and writes the actual operation to the journal (e.g. "rename foo/X to bar/Y"). Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. From jpiszcz at lucidpixels.com Wed Jun 21 11:35:48 2006 From: jpiszcz at lucidpixels.com (Justin Piszcz) Date: Wed, 21 Jun 2006 07:35:48 -0400 (EDT) Subject: Is there a way to cache a file system listing? Message-ID: I have a filesystem that has roughly ~600,000 files on it and every time a new client rsyncs this tree (after 10-20 minutes when the cache has expired) then it takes 5-10 minutes to re-traverse the tree during a new rsync. Is there a way, other than running find /path every minute or so, to keep the listing in memory so the rsyncs would run much faster? From Sinha_Himanshu at emc.com Mon Jun 19 18:18:12 2006 From: Sinha_Himanshu at emc.com (Sinha_Himanshu at emc.com) Date: Mon, 19 Jun 2006 14:18:12 -0400 Subject: Limited write bandwidth from ext3 Message-ID: <7E76AE153FDC3240BA7E82E23972F9FE01A0D490@CORPUSMX30B.corp.emc.com> We are running a benchmark that does single threaded 512 KB writes to a LUN on a CLARiiON storage array. The dual Xeon host (Dell 2650) with 4 GB of memory runs RHEL 4U3 We measured the write bandwidth for writes to the block device corresponding to the lun (e.g. /dev/sdb), a file in an ext2 filesystem and to a file in an ext3 file system. Write b/w for 512 KB writes Block device 312 MBps Ext2 file 247 MBps Ext3 file 130 MBps We are looking for ways to improve the ext3 file write bandwidth. Tracing of I/Os at the storage array shows that in the case of ext3 experiment, the workload does not keep the lun busy enough. Every 5 seconds there is an increase in I/O activity that lasts for 2-3 seconds. The lun then has very low activity for 2-3 seconds. It appears that the buffers at the host are flushed every 5 seconds and the flushing takes 2-3 seconds. To maximize write bandwidth, we would like to be in a situation where the buffers are flushed continuously to keep the lun constanly busy. That is what we see in the case of the ext2 file. In the case of ext2 we also see the host do quite a few ver large writes (up to 7784 KB). Thanks Himanshu Sinha From Sinha_Himanshu at emc.com Wed Jun 21 14:24:32 2006 From: Sinha_Himanshu at emc.com (Sinha_Himanshu at emc.com) Date: Wed, 21 Jun 2006 10:24:32 -0400 Subject: Limited write bandwidth from ext3 In-Reply-To: <20060621141150.GA25294@rap.rap.dk> Message-ID: <7E76AE153FDC3240BA7E82E23972F9FE01A0DD6B@CORPUSMX30B.corp.emc.com> I misspoke earlier - our data is from a RHEL 4U1 system - 2.6.9 kernel. We will try RHEL 4U3 soon. That will give us a later kernel. Thanks Himanshu -----Original Message----- From: Keld J?rn Simonsen [mailto:keld at dkuug.dk] Sent: Wednesday, June 21, 2006 10:12 AM To: Sinha, Himanshu Cc: ext3-users at redhat.com Subject: Re: Limited write bandwidth from ext3 On Mon, Jun 19, 2006 at 02:18:12PM -0400, Sinha_Himanshu at emc.com wrote: > We are running a benchmark that does single threaded 512 KB writes to a > LUN on a CLARiiON storage array. The dual Xeon host (Dell 2650) with 4 > GB of memory runs RHEL 4U3 > > We measured the write bandwidth for writes to the block device > corresponding to the lun (e.g. /dev/sdb), a file in an ext2 filesystem > and to a file in an ext3 file system. > Write b/w for 512 KB writes > Block device 312 MBps > Ext2 file 247 MBps > Ext3 file 130 MBps > > We are looking for ways to improve the ext3 file write bandwidth. > > Tracing of I/Os at the storage array shows that in the case of ext3 > experiment, the workload does not keep the lun busy enough. Every 5 > seconds there is an increase in I/O activity that lasts for 2-3 seconds. > The lun then has very low activity for 2-3 seconds. It appears that the > buffers at the host are flushed every 5 seconds and the flushing takes > 2-3 seconds. To maximize write bandwidth, we would like to be in a > situation where the buffers are flushed continuously to keep the lun > constanly busy. > That is what we see in the case of the ext2 file. > > In the case of ext2 we also see the host do quite a few ver large writes > (up to 7784 KB). Hmm, is the new kernel 2.6.17 addressing such issues? I understand that the new multibuffered implementation of ext3 may enhance the performance considerably. What kernel did you benchmark on? best regards keld From Nigel.Metheringham at dev.intechnology.co.uk Wed Jun 21 14:32:09 2006 From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Wed, 21 Jun 2006 15:32:09 +0100 Subject: Limited write bandwidth from ext3 In-Reply-To: <7E76AE153FDC3240BA7E82E23972F9FE01A0DD6B@CORPUSMX30B.corp.emc.com> References: <7E76AE153FDC3240BA7E82E23972F9FE01A0DD6B@CORPUSMX30B.corp.emc.com> Message-ID: <1150900330.29606.4.camel@angua.localnet> On Wed, 2006-06-21 at 10:24 -0400, Sinha_Himanshu at emc.com wrote: > I misspoke earlier - our data is from a RHEL 4U1 system - 2.6.9 kernel. > We will try RHEL 4U3 soon. That will give us a later kernel. Not much - still a 2.6.9, although it will have patches bringing in some later functionality. You can tune the buffer flushing period (normally done for laptops to prevent the disk spinning up - I have no idea what will happen if you set it right down, but it feels like you would be in uncharted territory there). You should be able to find info on tuning this if you look for stuff on laptops and ext3. Continuous write throughput sounds a bit more like something that XFS would do well. Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From herta.vandeneynde at cc.kuleuven.be Wed Jun 21 14:34:55 2006 From: herta.vandeneynde at cc.kuleuven.be (Herta Van den Eynde) Date: Wed, 21 Jun 2006 16:34:55 +0200 Subject: Limited write bandwidth from ext3 In-Reply-To: <7E76AE153FDC3240BA7E82E23972F9FE01A0D490@CORPUSMX30B.corp.emc.com> References: <7E76AE153FDC3240BA7E82E23972F9FE01A0D490@CORPUSMX30B.corp.emc.com> Message-ID: <4499590F.7060406@cc.kuleuven.be> Sinha_Himanshu at emc.com wrote: > We are running a benchmark that does single threaded 512 KB writes to a > LUN on a CLARiiON storage array. The dual Xeon host (Dell 2650) with 4 > GB of memory runs RHEL 4U3 > > We measured the write bandwidth for writes to the block device > corresponding to the lun (e.g. /dev/sdb), a file in an ext2 filesystem > and to a file in an ext3 file system. > Write b/w for 512 KB writes > Block device 312 MBps > Ext2 file 247 MBps > Ext3 file 130 MBps > > We are looking for ways to improve the ext3 file write bandwidth. > > Tracing of I/Os at the storage array shows that in the case of ext3 > experiment, the workload does not keep the lun busy enough. Every 5 > seconds there is an increase in I/O activity that lasts for 2-3 seconds. > The lun then has very low activity for 2-3 seconds. It appears that the > buffers at the host are flushed every 5 seconds and the flushing takes > 2-3 seconds. To maximize write bandwidth, we would like to be in a > situation where the buffers are flushed continuously to keep the lun > constanly busy. > That is what we see in the case of the ext2 file. > > In the case of ext2 we also see the host do quite a few ver large writes > (up to 7784 KB). > > Thanks > Himanshu Sinha > > _______________________________________________ > Ext3-users mailing list > Ext3-users at redhat.com > https://www.redhat.com/mailman/listinfo/ext3-users > Sounds like you are describing the default ext3 sync'ing feature. ext3 has a mount option "commit", with default value 5 seconds. It causes all data and metadata to be sync'ed every 5. (Cf. 'man mount') I'm not an expert, so I'm not sure what the potential impact might be (other than delaying sync times) if you change this value. Kind regards, Herta Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm From keld at dkuug.dk Wed Jun 21 14:11:50 2006 From: keld at dkuug.dk (Keld =?iso-8859-1?Q?J=F8rn?= Simonsen) Date: Wed, 21 Jun 2006 16:11:50 +0200 Subject: Limited write bandwidth from ext3 In-Reply-To: <7E76AE153FDC3240BA7E82E23972F9FE01A0D490@CORPUSMX30B.corp.emc.com> References: <7E76AE153FDC3240BA7E82E23972F9FE01A0D490@CORPUSMX30B.corp.emc.com> Message-ID: <20060621141150.GA25294@rap.rap.dk> On Mon, Jun 19, 2006 at 02:18:12PM -0400, Sinha_Himanshu at emc.com wrote: > We are running a benchmark that does single threaded 512 KB writes to a > LUN on a CLARiiON storage array. The dual Xeon host (Dell 2650) with 4 > GB of memory runs RHEL 4U3 > > We measured the write bandwidth for writes to the block device > corresponding to the lun (e.g. /dev/sdb), a file in an ext2 filesystem > and to a file in an ext3 file system. > Write b/w for 512 KB writes > Block device 312 MBps > Ext2 file 247 MBps > Ext3 file 130 MBps > > We are looking for ways to improve the ext3 file write bandwidth. > > Tracing of I/Os at the storage array shows that in the case of ext3 > experiment, the workload does not keep the lun busy enough. Every 5 > seconds there is an increase in I/O activity that lasts for 2-3 seconds. > The lun then has very low activity for 2-3 seconds. It appears that the > buffers at the host are flushed every 5 seconds and the flushing takes > 2-3 seconds. To maximize write bandwidth, we would like to be in a > situation where the buffers are flushed continuously to keep the lun > constanly busy. > That is what we see in the case of the ext2 file. > > In the case of ext2 we also see the host do quite a few ver large writes > (up to 7784 KB). Hmm, is the new kernel 2.6.17 addressing such issues? I understand that the new multibuffered implementation of ext3 may enhance the performance considerably. What kernel did you benchmark on? best regards keld From keld at dkuug.dk Wed Jun 21 16:53:00 2006 From: keld at dkuug.dk (Keld =?iso-8859-1?Q?J=F8rn?= Simonsen) Date: Wed, 21 Jun 2006 18:53:00 +0200 Subject: Limited write bandwidth from ext3 In-Reply-To: <7E76AE153FDC3240BA7E82E23972F9FE01A0DD6B@CORPUSMX30B.corp.emc.com> References: <20060621141150.GA25294@rap.rap.dk> <7E76AE153FDC3240BA7E82E23972F9FE01A0DD6B@CORPUSMX30B.corp.emc.com> Message-ID: <20060621165300.GA27568@rap.rap.dk> On Wed, Jun 21, 2006 at 10:24:32AM -0400, Sinha_Himanshu at emc.com wrote: > I misspoke earlier - our data is from a RHEL 4U1 system - 2.6.9 kernel. > We will try RHEL 4U3 soon. That will give us a later kernel. You need to go to 2.6.17 to get the performance enhancements I was talking about, and 2.6.17 is very new, released less than a week ago. I would compile that kernel myself for the testing. Best regards keld > Thanks > Himanshu > > -----Original Message----- > From: Keld J?rn Simonsen [mailto:keld at dkuug.dk] > Sent: Wednesday, June 21, 2006 10:12 AM > To: Sinha, Himanshu > Cc: ext3-users at redhat.com > Subject: Re: Limited write bandwidth from ext3 > > On Mon, Jun 19, 2006 at 02:18:12PM -0400, Sinha_Himanshu at emc.com wrote: > > We are running a benchmark that does single threaded 512 KB writes to a > > LUN on a CLARiiON storage array. The dual Xeon host (Dell 2650) with 4 > > GB of memory runs RHEL 4U3 > > > > We measured the write bandwidth for writes to the block device > > corresponding to the lun (e.g. /dev/sdb), a file in an ext2 filesystem > > and to a file in an ext3 file system. > > Write b/w for 512 KB writes > > Block device 312 MBps > > Ext2 file 247 MBps > > Ext3 file 130 MBps > > > > We are looking for ways to improve the ext3 file write bandwidth. > > > > Tracing of I/Os at the storage array shows that in the case of ext3 > > experiment, the workload does not keep the lun busy enough. Every 5 > > seconds there is an increase in I/O activity that lasts for 2-3 seconds. > > The lun then has very low activity for 2-3 seconds. It appears that the > > buffers at the host are flushed every 5 seconds and the flushing takes > > 2-3 seconds. To maximize write bandwidth, we would like to be in a > > situation where the buffers are flushed continuously to keep the lun > > constanly busy. > > That is what we see in the case of the ext2 file. > > > > In the case of ext2 we also see the host do quite a few ver large writes > > (up to 7784 KB). > > Hmm, is the new kernel 2.6.17 addressing such issues? > I understand that the new multibuffered implementation of ext3 > may enhance the performance considerably. > > What kernel did you benchmark on? > > best regards > keld > > _______________________________________________ > Ext3-users mailing list > Ext3-users at redhat.com > https://www.redhat.com/mailman/listinfo/ext3-users From kstrong at criminalinfo.net Wed Jun 21 19:15:38 2006 From: kstrong at criminalinfo.net (Kevin Strong) Date: Wed, 21 Jun 2006 15:15:38 -0400 Subject: Is there a way to cache a file system listing? In-Reply-To: References: Message-ID: <44999ADA.1060208@criminalinfo.net> I second this. I am having the same exact issue right now. Any suggestions would be appreciated. Justin Piszcz wrote: > I have a filesystem that has roughly ~600,000 files on it and every > time a new client rsyncs this tree (after 10-20 minutes when the cache > has expired) then it takes 5-10 minutes to re-traverse the tree during > a new rsync. Is there a way, other than running find /path every > minute or so, to keep the listing in memory so the rsyncs would run > much faster? > > _______________________________________________ > Ext3-users mailing list > Ext3-users at redhat.com > https://www.redhat.com/mailman/listinfo/ext3-users From niam.tni at googlemail.com Wed Jun 21 20:08:14 2006 From: niam.tni at googlemail.com (Stefan Drexleri) Date: Wed, 21 Jun 2006 22:08:14 +0200 Subject: viewing ext3 journal In-Reply-To: <20060621043510.GA5817@schatzie.adilger.int> References: <35ce7f5b0606200935p655a35a9i8b4d02dc571535dd@mail.gmail.com> <20060620181742.GV5817@schatzie.adilger.int> <35ce7f5b0606201257k816293aub8dc1120bcd61a35@mail.gmail.com> <20060620221447.GY5817@schatzie.adilger.int> <35ce7f5b0606201546n3e88102fk44ff871ac30206f3@mail.gmail.com> <20060621043510.GA5817@schatzie.adilger.int> Message-ID: <35ce7f5b0606211308l3b6abfecn6f2f4ab2f3e30b6f@mail.gmail.com> 2006/6/21, Andreas Dilger : > > Note that this would never be possible (or at least very easy) with ext3 > journaling since ext3 uses "block journaling", where the whole filesystem > block that is modified is written to the journal (e.g. one or two directory > leaf blocks and up to four inode table blocks are written to disk for a > rename). So you would have to decode raw data. I'm wondering, why ext3 developers didn't make debugfs can do that? Sure, you can do good file monitoring at higher level, but wouldn't such a human-readable fs journal the best report, you ever could get? I don't know if this feature would be of big interest, i'm curious. ;) greetings From tytso at mit.edu Wed Jun 21 20:39:13 2006 From: tytso at mit.edu (Theodore Tso) Date: Wed, 21 Jun 2006 16:39:13 -0400 Subject: Is there a way to cache a file system listing? In-Reply-To: <44999ADA.1060208@criminalinfo.net> References: <44999ADA.1060208@criminalinfo.net> Message-ID: <20060621203913.GE28159@thunk.org> On Wed, Jun 21, 2006 at 03:15:38PM -0400, Kevin Strong wrote: > Justin Piszcz wrote: > >I have a filesystem that has roughly ~600,000 files on it and every > >time a new client rsyncs this tree (after 10-20 minutes when the cache > >has expired) then it takes 5-10 minutes to re-traverse the tree during > >a new rsync. Is there a way, other than running find /path every > >minute or so, to keep the listing in memory so the rsyncs would run > >much faster? > > I second this. I am having the same exact issue right now. Any > suggestions would be appreciated. Are you sure the time is actually re-traversing the tree, and not calculating the per-file checksums? Running an rsync server does present a big load on the server, but traditionally it's not been a matter of whether or not the directories have been cached, but rather the fact that rsync doesn't cache the per-file checksums, and has to recalculate them all each time a new client connects. - Ted From kstrong at criminalinfo.net Wed Jun 21 20:43:44 2006 From: kstrong at criminalinfo.net (Kevin Strong) Date: Wed, 21 Jun 2006 16:43:44 -0400 Subject: Is there a way to cache a file system listing? In-Reply-To: <20060621203913.GE28159@thunk.org> References: <44999ADA.1060208@criminalinfo.net> <20060621203913.GE28159@thunk.org> Message-ID: <4499AF80.7040301@criminalinfo.net> Theodore Tso wrote: >On Wed, Jun 21, 2006 at 03:15:38PM -0400, Kevin Strong wrote: > > >>Justin Piszcz wrote: >> >> >>>I have a filesystem that has roughly ~600,000 files on it and every >>>time a new client rsyncs this tree (after 10-20 minutes when the cache >>>has expired) then it takes 5-10 minutes to re-traverse the tree during >>>a new rsync. Is there a way, other than running find /path every >>>minute or so, to keep the listing in memory so the rsyncs would run >>>much faster? >>> >>> >>I second this. I am having the same exact issue right now. Any >>suggestions would be appreciated. >> >> > >Are you sure the time is actually re-traversing the tree, and not >calculating the per-file checksums? Running an rsync server does >present a big load on the server, but traditionally it's not been a >matter of whether or not the directories have been cached, but rather >the fact that rsync doesn't cache the per-file checksums, and has to >recalculate them all each time a new client connects. > > - Ted > > > For me, this is on the client side, not the server side. Sorry; should have clarified. It's definitely an issue with the directory tree falling out of the FS cache. Are you aware of a solution to this? Kevin Strong Criminal Information Network, Inc. From adilger at clusterfs.com Wed Jun 21 20:53:32 2006 From: adilger at clusterfs.com (Andreas Dilger) Date: Wed, 21 Jun 2006 14:53:32 -0600 Subject: Limited write bandwidth from ext3 In-Reply-To: <7E76AE153FDC3240BA7E82E23972F9FE01A0D490@CORPUSMX30B.corp.emc.com> References: <7E76AE153FDC3240BA7E82E23972F9FE01A0D490@CORPUSMX30B.corp.emc.com> Message-ID: <20060621205332.GK5817@schatzie.adilger.int> On Jun 19, 2006 14:18 -0400, Sinha_Himanshu at emc.com wrote: > We measured the write bandwidth for writes to the block device > corresponding to the lun (e.g. /dev/sdb), a file in an ext2 filesystem > and to a file in an ext3 file system. > Write b/w for 512 KB writes > Block device 312 MBps > Ext2 file 247 MBps > Ext3 file 130 MBps > > We are looking for ways to improve the ext3 file write bandwidth. Have a look at the extents+mballoc+delalloc patches from Alex Tomas: ftp://ftp.lustre.org/pub/people/alex/2.6.16.8/ Mount the filesystem with "-o extents,mballoc,delalloc" to enable this. They noticably improve IO performance while also reducing the CPU load for ext3. The extent patches are approved by all of the ext3 developers and will be supported upstream fairly soon (in the kernel and e2fsprogs), and mballoc+delalloc will follow on afterward. NOTE: the extents on-disk format is incompatible with older kernels, so at this stage consider it "for benchmarking only". Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. From qiyong at freeforge.net Wed Jun 21 15:42:14 2006 From: qiyong at freeforge.net (Coywolf Qi Hunt) Date: Wed, 21 Jun 2006 11:42:14 -0400 Subject: How to learn about ext3? In-Reply-To: <200605212140.21463.julio@jmaranhao.com> References: <200605212140.21463.julio@jmaranhao.com> Message-ID: <20060621154214.GA16877@everest.sosdg.org> On Sun, May 21, 2006 at 09:40:21PM -0300, J?lio Maranh?o wrote: > Hi, > > I want to learn about ext3 fs from the basics to the inner details. Some hints > about links that have that info well explained? EXT3, Journaling Filesystem 20 July, 2000 Dr. Stephen Tweedie http://olstrans.sourceforge.net/release/OLS2000-ext3/OLS2000-ext3.html -- Coywolf Qi Hunt From mr._x at shaw.ca Fri Jun 23 02:09:25 2006 From: mr._x at shaw.ca (..:::BeOS Mr. X:::..) Date: Thu, 22 Jun 2006 19:09:25 -0700 Subject: Needed help to fix corrupted ext3 fs Message-ID: <449B4D55.6090404@shaw.ca> I have been trying very hard to seek help with my very complex issue but so far none have been successful. So I would like to try this mailing list, maybe there are some experts who know what they're talking about. Please refer to my experts-exchange question, all the required information will be there. It is more practical to send you to the webpage than paste out what I've done. http://www.experts-exchange.com/Operating_Systems/Linux/Q_21882610.html Hope any can help find THE solution. From kstrong at criminalinfo.net Fri Jun 23 12:54:39 2006 From: kstrong at criminalinfo.net (Kevin Strong) Date: Fri, 23 Jun 2006 08:54:39 -0400 Subject: Needed help to fix corrupted ext3 fs In-Reply-To: <449B4D55.6090404@shaw.ca> References: <449B4D55.6090404@shaw.ca> Message-ID: <449BE48F.9060501@criminalinfo.net> Does the filesystem mount okay on boot (but the apps you mentioned don't start) or do you have to drop down to emergency repair root, log in, and init 3 yourself? Also, could you send the output of a simple 'mount' command as well as the output from 'df -Tla', and 'cat /proc/filesystems', 'cat /proc/ide/hda/settings', and 'cat /proc/ide/hda/driver' ? I assume you've already tried 'mount /dev/hda3 -oremount,rw' ? ..:::BeOS Mr. X:::.. wrote: > I have been trying very hard to seek help with my very complex issue > but so far none have been successful. So I would like to try this > mailing list, maybe there are some experts who know what they're > talking about. > Please refer to my experts-exchange question, all the required > information will be there. It is more practical to send you to the > webpage than paste out what I've done. > http://www.experts-exchange.com/Operating_Systems/Linux/Q_21882610.html > Hope any can help find THE solution. > > _______________________________________________ > Ext3-users mailing list > Ext3-users at redhat.com > https://www.redhat.com/mailman/listinfo/ext3-users From johann.lombardi at bull.net Fri Jun 23 14:17:03 2006 From: johann.lombardi at bull.net (Johann Lombardi) Date: Fri, 23 Jun 2006 16:17:03 +0200 Subject: Needed help to fix corrupted ext3 fs In-Reply-To: <449B4D55.6090404@shaw.ca> References: <449B4D55.6090404@shaw.ca> Message-ID: <20060623141703.GA18540@lombardij> > http://www.experts-exchange.com/Operating_Systems/Linux/Q_21882610.html According to your fstab, you use LVM logical volumes. You should run e2fsck on /dev/VolGroup00/LogVol00 instead of /dev/hda3. Johann From mr._x at shaw.ca Fri Jun 23 21:22:39 2006 From: mr._x at shaw.ca (..:::BeOS Mr. X:::..) Date: Fri, 23 Jun 2006 14:22:39 -0700 Subject: Needed help to fix corrupted ext3 fs In-Reply-To: <20060623141703.GA18540@lombardij> References: <449B4D55.6090404@shaw.ca> <20060623141703.GA18540@lombardij> Message-ID: <449C5B9F.1000900@shaw.ca> Okay, I recieved three usefull replies from these people: Andreas Dilger adilger at clusterfs.com Kevin Strong kstrong at criminalinfo.net Johann Lombardi ohann.lombardi at bull.net Here I attempt to reply to all of them at once. All the suggestions were performed while booted to the Mandriva 2006 cli, in su mode. Andreas Dilger's suggestion: e2fsck -fp /dev/VolGroup00/LogVol00 /dev/VolGroup00/LogVol00: 165780/14974976 files (2.8% non-contiguous), 5773411/299253796 blocks Johann Lombardi's suggestion: e2fsck on /dev/VolGroup00/LogVol00 instead of /dev/hda3. done, same suggestion as Andreas. The most exhaustive work was done with Kevin Strong's suggestions. send the output of mount /dev/hda3 -oremount,rw [mntent]: line 2 in /etc/fstab is bad [mntent]: line 4 in /etc/fstab is bad [mntent]: line 6 in /etc/fstab is bad mount: can't find /dev/hda3 in /etc/fstab pr /etc/mtab df -Tla Filesytem Type Size Used Avail Use% Mounted on none proc 0 0 0 - /proc df: '/proc/bus/usb': No such file or directory none sysfs 0 0 0 - /sys cat /proc/ide/hda/settings name value min max mode ---- ----- --- --- ---- acoustic 0 0 254 rw address 1 0 2 rw bios_cyl 24792 0 65535 rw bios_head 255 0 255 rw bios_sect 63 0 63 rw bswap 0 0 1 rw current_speed 70 0 70 r failures 0 0 65535 rw init_speed 70 0 70 rw is_32bit 0 0 3 rw keep settings 0 0 1 rw lun 0 0 7 rw max_failures 1 0 65535 rw mult count 16 0 16 rw nice1 1 0 1 rw nowerr 0 0 1 rw number 0 0 3 rw pio_mode write-only 0 255 w unmaskirq 0 0 1 rw unsing_dma 1 0 1 rw wcache 1 0 1 rw cat /proc/filesystem nodev sysfs nodev rootfs nodev bdev nodev proc nodev sockfs nodev pipfs nodev tmpfs nodev inotifyfs nodev eventpollfs nodev devpts ext2 cramfs dodev ramfs nodev devfs nodev mqueue ext3 cat /proc/ide/hda/driver ide-disk version 1.18 -------- Now hopefully more progress can be made now that I've given all the required information. Hope you can help! From kstrong at criminalinfo.net Fri Jun 23 21:50:04 2006 From: kstrong at criminalinfo.net (Kevin Strong) Date: Fri, 23 Jun 2006 17:50:04 -0400 Subject: Needed help to fix corrupted ext3 fs In-Reply-To: <449C5B9F.1000900@shaw.ca> References: <449B4D55.6090404@shaw.ca> <20060623141703.GA18540@lombardij> <449C5B9F.1000900@shaw.ca> Message-ID: <449C620C.8070100@criminalinfo.net> If I would have known it was a logical volume (didn't pay enough attention because I was at work), I wouldn't have suggested what I did. Anyway, what specifically happens when you boot up? Does it force you to a root prompt or does it boot up but refuse write access? In any event, the e2fsck -fp should have fixed any minor problems and reported larger ones but failed to do so. What is the entire contents of your /etc/fstab? ..:::BeOS Mr. X:::.. wrote: > Okay, I recieved three usefull replies from these people: > Andreas Dilger adilger at clusterfs.com > Kevin Strong kstrong at criminalinfo.net > Johann Lombardi ohann.lombardi at bull.net > > Here I attempt to reply to all of them at once. All the suggestions > were performed while booted to the Mandriva 2006 cli, in su mode. > > Andreas Dilger's suggestion: > e2fsck -fp /dev/VolGroup00/LogVol00 > > /dev/VolGroup00/LogVol00: 165780/14974976 files (2.8% non-contiguous), > 5773411/299253796 blocks > > Johann Lombardi's suggestion: > e2fsck on /dev/VolGroup00/LogVol00 instead of /dev/hda3. > > done, same suggestion as Andreas. > > The most exhaustive work was done with Kevin Strong's suggestions. > send the output of mount /dev/hda3 -oremount,rw > > [mntent]: line 2 in /etc/fstab is bad > [mntent]: line 4 in /etc/fstab is bad > [mntent]: line 6 in /etc/fstab is bad > mount: can't find /dev/hda3 in /etc/fstab pr /etc/mtab > > df -Tla > Filesytem Type Size Used Avail Use% Mounted on > none proc 0 0 0 - /proc > df: '/proc/bus/usb': No such file or directory > none sysfs 0 0 0 - /sys > > cat /proc/ide/hda/settings > name value min max mode > ---- ----- --- --- ---- > acoustic 0 0 254 rw > address 1 0 2 rw > bios_cyl 24792 0 65535 rw > bios_head 255 0 255 rw > bios_sect 63 0 63 rw > bswap 0 0 1 rw > current_speed 70 0 70 r > failures 0 0 65535 rw > init_speed 70 0 70 rw > is_32bit 0 0 3 rw > keep settings 0 0 1 rw > lun 0 0 7 rw > max_failures 1 0 65535 rw > mult count 16 0 16 rw > nice1 1 0 1 rw > nowerr 0 0 1 rw > number 0 0 3 rw > pio_mode write-only 0 255 w > unmaskirq 0 0 1 rw > unsing_dma 1 0 1 rw > wcache 1 0 1 rw > > cat /proc/filesystem > nodev sysfs > nodev rootfs > nodev bdev > nodev proc > nodev sockfs > nodev pipfs > nodev tmpfs > nodev inotifyfs > nodev eventpollfs > nodev devpts > ext2 > cramfs > dodev ramfs > nodev devfs > nodev mqueue > ext3 > > cat /proc/ide/hda/driver > ide-disk version 1.18 > > -------- > > Now hopefully more progress can be made now that I've given all the > required information. Hope you can help! > > _______________________________________________ > Ext3-users mailing list > Ext3-users at redhat.com > https://www.redhat.com/mailman/listinfo/ext3-users From dzila at tassadar.physics.auth.gr Sat Jun 24 19:42:06 2006 From: dzila at tassadar.physics.auth.gr (Dimitris Zilaskos) Date: Sat, 24 Jun 2006 22:42:06 +0300 (EEST) Subject: recover data from linear raid Message-ID: Hello, I had a scientific linux 3.0.4 system (rhel compatible), with 3 ide disks, one for / and two others in linear raid (250 gb and 300 gb each). This system was obsoleted so i move the raid disks to a new scientific linux 3.0.7 installation. However, the raid array was not detected ( I put the disks on the same channels and same master/lsave setup as in the previous setup). In fact fdisk reports that the disks are not partitioned. I had around 70 gb data on that array I would like to recover. I used dd on the disks and strings on the resulting file. The data is there but fsck complains about superblocks and fails. Recommentations on how to proceed are greatly appreciated. Best regards, -- ============================================================================ Dimitris Zilaskos Department of Physics @ Aristotle University of Thessaloniki , Greece PGP key : http://tassadar.physics.auth.gr/~dzila/pgp_public_key.asc http://egnatia.ee.auth.gr/~dzila/pgp_public_key.asc MD5sum : de2bd8f73d545f0e4caf3096894ad83f pgp_public_key.asc ============================================================================ From evilninja at gmx.net Sun Jun 25 03:30:35 2006 From: evilninja at gmx.net (christian) Date: Sun, 25 Jun 2006 04:30:35 +0100 (BST) Subject: recover data from linear raid In-Reply-To: References: Message-ID: On Sat, 24 Jun 2006, Dimitris Zilaskos wrote: > scientific linux 3.0.7 installation. However, the raid array was not detected > ( I put the disks on the same channels and same master/lsave setup as in the well, first of all: you have to make sure that your raid array is set up correctly. no fs-magic can help here if the underlying blockdevice has been mangled. > previous setup). In fact fdisk reports that the disks are not > partitioned. perhaps the raid-array has been created from disks, not from partitions? e.g. - /dev/md0 out of /dev/sda, /dev/sdb, /dev/sdc instead of - /dev/md0 out of /dev/sda1, /dev/sdb1, /dev/sdc2 > dd on the disks and strings on the resulting file. The data is there but > fsck complains about superblocks and fails. please provide errorlogs, fsck's, fdisk's output of what you did... -- BOFH excuse #385: Dyslexics retyping hosts file on servers From neilb at cse.unsw.edu.au Mon Jun 26 06:37:35 2006 From: neilb at cse.unsw.edu.au (Neil Brown) Date: Mon, 26 Jun 2006 16:37:35 +1000 Subject: recover data from linear raid In-Reply-To: message from Dimitris Zilaskos on Saturday June 24 References: Message-ID: <17567.32943.269414.967812@cse.unsw.edu.au> On Saturday June 24, dzila at tassadar.physics.auth.gr wrote: > > Hello, > > I had a scientific linux 3.0.4 system (rhel compatible), with 3 > ide disks, one for / and two others in linear raid (250 gb and 300 gb > each). > This system was obsoleted so i move the raid disks to a new > scientific linux 3.0.7 installation. However, the raid array was not > detected ( I put the disks on the same channels and same master/lsave > setup as in the previous setup). In fact fdisk reports that the disks are > not partitioned. > I had around 70 gb data on that array I would like to recover. I > used dd on the disks and strings on the resulting file. The data is there > but fsck complains about superblocks and fails. > > Recommentations on how to proceed are greatly appreciated. As Christian said, specific error message help a lot. Assume the two devices are hdc and hde, fdisk -l /dev/hdc fdisk -l /dev/hde mdadm -E /dev/hdc mdadm -E /dev/hde and my best guess mdadm --build /dev/md0 --level linear --raid-disks 2 /dev/hdc /dev/hde fsck -n /dev/md0 (and linux-raid at vger.kernel.org might be a better mailing list for this particular sort of problem). NeilBrown From dzila at tassadar.physics.auth.gr Mon Jun 26 13:48:10 2006 From: dzila at tassadar.physics.auth.gr (Dimitris Zilaskos) Date: Mon, 26 Jun 2006 16:48:10 +0300 (EEST) Subject: recover data from linear raid In-Reply-To: <17566.13544.15613.709664@cse.unsw.edu.au> References: <17566.13544.15613.709664@cse.unsw.edu.au> Message-ID: > > As Christian said, specific error message help a lot. > Assume the two devices are hdc and hde, > > fdisk -l /dev/hdc > fdisk -l /dev/hde > mdadm -E /dev/hdc > mdadm -E /dev/hde > > and my best guess > > mdadm --build /dev/md0 --level linear --raid-disks 2 /dev/hdc /dev/hde > fsck -n /dev/md0 > > (and linux-raid at vger.kernel.org might be a better mailing list for > this particular sort of problem). Disk /dev/hdb: 250.0 GB, 250059350016 bytes 255 heads, 63 sectors/track, 30401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System [root at node004 root]# fdisk -l /dev/hdc Disk /dev/hdc: 300.0 GB, 300090728448 bytes 255 heads, 63 sectors/track, 36483 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System [root at node004 root]# mdadm -E /dev/hdb /dev/hdb: Magic : a92b4efc Version : 00.90.00 UUID : 293be3e8:5a7ac6e7:adefc469:84f8aefb Creation Time : Fri Jun 23 15:47:10 2006 Raid Level : linear Device Size : 244198464 (232.89 GiB 250.06 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Update Time : Fri Jun 23 15:48:43 2006 State : clean, no-errors Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Checksum : f790e07f - correct Events : 0.2 Rounding : 32K Number Major Minor RaidDevice State this 0 3 64 0 active sync /dev/hdb 0 0 3 64 0 active sync /dev/hdb 1 1 22 0 1 active sync /dev/hdc [root at node004 root]# mdadm -E /dev/hdc /dev/hdc: Magic : a92b4efc Version : 00.90.00 UUID : 293be3e8:5a7ac6e7:adefc469:84f8aefb Creation Time : Fri Jun 23 15:47:10 2006 Raid Level : linear Device Size : 244198464 (232.89 GiB 250.06 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Update Time : Fri Jun 23 15:48:43 2006 State : clean, no-errors Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Checksum : f790e054 - correct Events : 0.2 Rounding : 32K Number Major Minor RaidDevice State this 1 22 0 1 active sync /dev/hdc 0 0 3 64 0 active sync /dev/hdb 1 1 22 0 1 active sync /dev/hdc [root at node004 root]# mdadm --build /dev/md0 --level linear --raid-disks 2 /dev/hdb /dev/hdc mdadm: array /dev/md0 built and started. fsck -n /dev/md0 fsck 1.32 (09-Nov-2002) e2fsck 1.32 (09-Nov-2002) Couldn't find ext2 superblock, trying backup blocks... fsck.ext2: Bad magic number in super-block while trying to open /dev/md0 The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 fsck -b 8193 /dev/md0 fsck 1.32 (09-Nov-2002) e2fsck 1.32 (09-Nov-2002) fsck.ext2: Bad magic number in super-block while trying to open /dev/md0 The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 During a recovery attemp today by mistake I created a mirror array with hdb as the primary and hdc as the secondary. I interrupted the array creation almost immediately, but part of the hdc was overwritten. However the array never held more than 70 gbytes of data, so I hope everything is intact on hdb :/ Thank you all for your kind help:) -- ============================================================================ Dimitris Zilaskos Department of Physics @ Aristotle University of Thessaloniki , Greece PGP key : http://tassadar.physics.auth.gr/~dzila/pgp_public_key.asc http://egnatia.ee.auth.gr/~dzila/pgp_public_key.asc MD5sum : de2bd8f73d545f0e4caf3096894ad83f pgp_public_key.asc ============================================================================ From dzila at tassadar.physics.auth.gr Mon Jun 26 15:21:44 2006 From: dzila at tassadar.physics.auth.gr (Dimitris Zilaskos) Date: Mon, 26 Jun 2006 18:21:44 +0300 (EEST) Subject: recover data from linear raid In-Reply-To: References: <17566.13544.15613.709664@cse.unsw.edu.au> Message-ID: I managed to get the hard disk of the retired system and this is its raid-related boot log: md: Autodetecting RAID arrays. [events: 0000004d] [events: 0000004d] md: autorun ... md: considering hdb1 ... md: adding hdb1 ... md: adding hdc1 ... md: created md0 md: bind md: bind md: running: md: hdb1's event counter: 0000004d md: hdc1's event counter: 0000004d md0: max total readahead window set to 512k md0: 2 data-disks, max readahead per data-disk: 256k raid0: looking at hdb1 raid0: comparing hdb1(244195904) with hdb1(244195904) raid0: END raid0: ==> UNIQUE raid0: 1 zones raid0: looking at hdc1 raid0: comparing hdc1(293049600) with hdb1(244195904) raid0: NOT EQUAL raid0: comparing hdc1(293049600) with hdc1(293049600) raid0: END raid0: ==> UNIQUE raid0: 2 zones raid0: FINAL 2 zones raid0: zone 0 raid0: checking hdb1 ... contained as device 0 (244195904) is smallest!. raid0: checking hdc1 ... contained as device 1 raid0: zone->nb_dev: 2, size: 488391808 raid0: current zone offset: 244195904 raid0: zone 1 raid0: checking hdb1 ... nope. raid0: checking hdc1 ... contained as device 0 (293049600) is smallest!. raid0: zone->nb_dev: 1, size: 48853696 raid0: current zone offset: 293049600 raid0: done. raid0 : md_size is 537245504 blocks. raid0 : conf->smallest->size is 48853696 blocks. raid0 : nb_zone is 11. raid0 : Allocating 88 bytes for hash. md: ... autorun DONE. >> >> As Christian said, specific error message help a lot. >> Assume the two devices are hdc and hde, >> >> fdisk -l /dev/hdc >> fdisk -l /dev/hde >> mdadm -E /dev/hdc >> mdadm -E /dev/hde >> >> and my best guess >> >> mdadm --build /dev/md0 --level linear --raid-disks 2 /dev/hdc /dev/hde >> fsck -n /dev/md0 >> >> (and linux-raid at vger.kernel.org might be a better mailing list for >> this particular sort of problem). > > Disk /dev/hdb: 250.0 GB, 250059350016 bytes > 255 heads, 63 sectors/track, 30401 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > > Device Boot Start End Blocks Id System > [root at node004 root]# fdisk -l /dev/hdc > > Disk /dev/hdc: 300.0 GB, 300090728448 bytes > 255 heads, 63 sectors/track, 36483 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > > Device Boot Start End Blocks Id System > [root at node004 root]# mdadm -E /dev/hdb > /dev/hdb: > Magic : a92b4efc > Version : 00.90.00 > UUID : 293be3e8:5a7ac6e7:adefc469:84f8aefb > Creation Time : Fri Jun 23 15:47:10 2006 > Raid Level : linear > Device Size : 244198464 (232.89 GiB 250.06 GB) > Raid Devices : 2 > Total Devices : 2 > Preferred Minor : 0 > > Update Time : Fri Jun 23 15:48:43 2006 > State : clean, no-errors > Active Devices : 2 > Working Devices : 2 > Failed Devices : 0 > Spare Devices : 0 > Checksum : f790e07f - correct > Events : 0.2 > > Rounding : 32K > > Number Major Minor RaidDevice State > this 0 3 64 0 active sync /dev/hdb > 0 0 3 64 0 active sync /dev/hdb > 1 1 22 0 1 active sync /dev/hdc > [root at node004 root]# mdadm -E /dev/hdc > /dev/hdc: > Magic : a92b4efc > Version : 00.90.00 > UUID : 293be3e8:5a7ac6e7:adefc469:84f8aefb > Creation Time : Fri Jun 23 15:47:10 2006 > Raid Level : linear > Device Size : 244198464 (232.89 GiB 250.06 GB) > Raid Devices : 2 > Total Devices : 2 > Preferred Minor : 0 > > Update Time : Fri Jun 23 15:48:43 2006 > State : clean, no-errors > Active Devices : 2 > Working Devices : 2 > Failed Devices : 0 > Spare Devices : 0 > Checksum : f790e054 - correct > Events : 0.2 > > Rounding : 32K > > Number Major Minor RaidDevice State > this 1 22 0 1 active sync /dev/hdc > 0 0 3 64 0 active sync /dev/hdb > 1 1 22 0 1 active sync /dev/hdc > [root at node004 root]# mdadm --build /dev/md0 --level linear --raid-disks 2 > /dev/hdb /dev/hdc > mdadm: array /dev/md0 built and started. > > fsck -n /dev/md0 > fsck 1.32 (09-Nov-2002) > e2fsck 1.32 (09-Nov-2002) > Couldn't find ext2 superblock, trying backup blocks... > fsck.ext2: Bad magic number in super-block while trying to open /dev/md0 > > The superblock could not be read or does not describe a correct ext2 > filesystem. If the device is valid and it really contains an ext2 > filesystem (and not swap or ufs or something else), then the superblock > is corrupt, and you might try running e2fsck with an alternate superblock: > e2fsck -b 8193 > > fsck -b 8193 /dev/md0 > fsck 1.32 (09-Nov-2002) > e2fsck 1.32 (09-Nov-2002) > fsck.ext2: Bad magic number in super-block while trying to open /dev/md0 > > The superblock could not be read or does not describe a correct ext2 > filesystem. If the device is valid and it really contains an ext2 > filesystem (and not swap or ufs or something else), then the superblock > is corrupt, and you might try running e2fsck with an alternate superblock: > e2fsck -b 8193 > > > During a recovery attemp today by mistake I created a mirror array > with hdb as the primary and hdc as the secondary. I interrupted the array > creation almost immediately, but part of the hdc was overwritten. However the > array never held more than 70 gbytes of data, so I hope everything is intact > on hdb :/ > > > Thank you all for your kind help:) > -- > ============================================================================ > > Dimitris Zilaskos > > Department of Physics @ Aristotle University of Thessaloniki , Greece > PGP key : http://tassadar.physics.auth.gr/~dzila/pgp_public_key.asc > http://egnatia.ee.auth.gr/~dzila/pgp_public_key.asc > MD5sum : de2bd8f73d545f0e4caf3096894ad83f pgp_public_key.asc > ============================================================================ > > _______________________________________________ > Ext3-users mailing list > Ext3-users at redhat.com > https://www.redhat.com/mailman/listinfo/ext3-users > From dzila at tassadar.physics.auth.gr Mon Jun 26 15:40:14 2006 From: dzila at tassadar.physics.auth.gr (Dimitris Zilaskos) Date: Mon, 26 Jun 2006 18:40:14 +0300 (EEST) Subject: recover data from linear raid In-Reply-To: References: <17566.13544.15613.709664@cse.unsw.edu.au> Message-ID: This is what I get now, after creating with fdisk /dev/hdb1 and /dev/hdc1 as linux raid autodetect partitions mdadm -E /dev/hdb1 /dev/hdb1: Magic : a92b4efc Version : 00.90.00 UUID : a7e90d4b:f347bd0e:07ebf941:e718f695 Creation Time : Wed Mar 16 18:14:25 2005 Raid Level : raid0 Device Size : 244195904 (232.88 GiB 250.06 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Update Time : Wed Jun 21 21:57:37 2006 State : clean, no-errors Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Checksum : c8c21ed8 - correct Events : 0.82 Chunk Size : 64K Number Major Minor RaidDevice State this 0 3 65 0 active sync /dev/hdb1 0 0 3 65 0 active sync /dev/hdb1 1 1 22 1 1 active sync /dev/hdc1 [root at node004 root]# mdadm -E /dev/hdc1 /dev/hdc1: Magic : a92b4efc Version : 00.90.00 UUID : a7e90d4b:f347bd0e:07ebf941:e718f695 Creation Time : Wed Mar 16 18:14:25 2005 Raid Level : raid0 Device Size : 244195904 (232.88 GiB 250.06 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Update Time : Wed Jun 21 21:57:37 2006 State : clean, no-errors Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Checksum : c8c21ead - correct Events : 0.82 Chunk Size : 64K Number Major Minor RaidDevice State this 1 22 1 1 active sync /dev/hdc1 0 0 3 65 0 active sync /dev/hdb1 1 1 22 1 1 active sync /dev/hdc1 -- ============================================================================ Dimitris Zilaskos Department of Physics @ Aristotle University of Thessaloniki , Greece PGP key : http://tassadar.physics.auth.gr/~dzila/pgp_public_key.asc http://egnatia.ee.auth.gr/~dzila/pgp_public_key.asc MD5sum : de2bd8f73d545f0e4caf3096894ad83f pgp_public_key.asc ============================================================================ From neilb at cse.unsw.edu.au Tue Jun 27 01:23:10 2006 From: neilb at cse.unsw.edu.au (Neil Brown) Date: Tue, 27 Jun 2006 11:23:10 +1000 Subject: recover data from linear raid In-Reply-To: message from Dimitris Zilaskos on Monday June 26 References: <17566.13544.15613.709664@cse.unsw.edu.au> Message-ID: <17568.34942.243102.778519@cse.unsw.edu.au> On Monday June 26, dzila at tassadar.physics.auth.gr wrote: > > This is what I get now, after creating with fdisk /dev/hdb1 and > /dev/hdc1 as linux raid autodetect partitions So I'm totally confused now. You said it was 'linear', but the boot log showed 'raid0'. The drives didn't have a partition table on them, yet it is clear from the old boot log that the did. Are you sure they are the same drives, 'cause it doesn't seem like it. You could try hunting for ext3 superblocks on the device. There might be an easier way but od -x /dev/hdb | grep '^.....60 .... .... .... .... ef53 ' should find them. Once you have this information we might be able to make something work. But I feel the chances are dwindling. NeilBrown From adilger at clusterfs.com Tue Jun 27 07:23:34 2006 From: adilger at clusterfs.com (Andreas Dilger) Date: Tue, 27 Jun 2006 01:23:34 -0600 Subject: recover data from linear raid In-Reply-To: <17568.34942.243102.778519@cse.unsw.edu.au> References: <17566.13544.15613.709664@cse.unsw.edu.au> <17568.34942.243102.778519@cse.unsw.edu.au> Message-ID: <20060627072334.GA5817@schatzie.adilger.int> On Jun 27, 2006 11:23 +1000, Neil Brown wrote: > You could try hunting for ext3 superblocks on the device. There might > be an easier way but > > od -x /dev/hdb | grep '^.....60 .... .... .... .... ef53 ' Compile the "findsuper" tool from e2fsprogs - it was made for this. Also possible to use "gpart". Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. From dzila at tassadar.physics.auth.gr Tue Jun 27 13:49:55 2006 From: dzila at tassadar.physics.auth.gr (Dimitris Zilaskos) Date: Tue, 27 Jun 2006 16:49:55 +0300 (EEST) Subject: recover data from linear raid In-Reply-To: <17568.34942.243102.778519@cse.unsw.edu.au> References: <17566.13544.15613.709664@cse.unsw.edu.au> <17568.34942.243102.778519@cse.unsw.edu.au> Message-ID: On Tue, 27 Jun 2006, Neil Brown wrote: > On Monday June 26, dzila at tassadar.physics.auth.gr wrote: >> >> This is what I get now, after creating with fdisk /dev/hdb1 and >> /dev/hdc1 as linux raid autodetect partitions > > So I'm totally confused now. > > You said it was 'linear', but the boot log showed 'raid0'. You aire absolutely right. Me bad > The drives didn't have a partition table on them, yet it is clear from > the old boot log that the did. Are you sure they are the same drives, > 'cause it doesn't seem like it. That's the root of my problem...when I moved the disks to the new system the disks showed up as unpartitioned. > You could try hunting for ext3 superblocks on the device. There might > be an easier way but > > od -x /dev/hdb | grep '^.....60 .... .... .... .... ef53 ' > > should find them. Once you have this information we might be able to > make something work. But I feel the chances are dwindling. > Me too. In any case the data was not that critical, so I will play around a little more before I give up. Thank you all for your help:) -- ============================================================================ Dimitris Zilaskos Department of Physics @ Aristotle University of Thessaloniki , Greece PGP key : http://tassadar.physics.auth.gr/~dzila/pgp_public_key.asc http://egnatia.ee.auth.gr/~dzila/pgp_public_key.asc MD5sum : de2bd8f73d545f0e4caf3096894ad83f pgp_public_key.asc ============================================================================ From sct at redhat.com Tue Jun 27 19:55:08 2006 From: sct at redhat.com (Stephen C. Tweedie) Date: Tue, 27 Jun 2006 20:55:08 +0100 Subject: viewing ext3 journal In-Reply-To: <35ce7f5b0606211308l3b6abfecn6f2f4ab2f3e30b6f@mail.gmail.com> References: <35ce7f5b0606200935p655a35a9i8b4d02dc571535dd@mail.gmail.com> <20060620181742.GV5817@schatzie.adilger.int> <35ce7f5b0606201257k816293aub8dc1120bcd61a35@mail.gmail.com> <20060620221447.GY5817@schatzie.adilger.int> <35ce7f5b0606201546n3e88102fk44ff871ac30206f3@mail.gmail.com> <20060621043510.GA5817@schatzie.adilger.int> <35ce7f5b0606211308l3b6abfecn6f2f4ab2f3e30b6f@mail.gmail.com> Message-ID: <1151438108.5230.29.camel@sisko.sctweedie.blueyonder.co.uk> Hi, On Wed, 2006-06-21 at 22:08 +0200, Stefan Drexleri wrote: > So you would have to decode raw data. I'm wondering, why ext3 > developers didn't make debugfs can do that? They did; try "logdump". It's still done at block level, but it provides some ability to browse the log for all occurences of a given block in the log etc. --Stephen From niam.tni at googlemail.com Wed Jun 28 19:51:05 2006 From: niam.tni at googlemail.com (Stefan Drexleri) Date: Wed, 28 Jun 2006 21:51:05 +0200 Subject: viewing ext3 journal In-Reply-To: <1151438108.5230.29.camel@sisko.sctweedie.blueyonder.co.uk> References: <35ce7f5b0606200935p655a35a9i8b4d02dc571535dd@mail.gmail.com> <20060620181742.GV5817@schatzie.adilger.int> <35ce7f5b0606201257k816293aub8dc1120bcd61a35@mail.gmail.com> <20060620221447.GY5817@schatzie.adilger.int> <35ce7f5b0606201546n3e88102fk44ff871ac30206f3@mail.gmail.com> <20060621043510.GA5817@schatzie.adilger.int> <35ce7f5b0606211308l3b6abfecn6f2f4ab2f3e30b6f@mail.gmail.com> <1151438108.5230.29.camel@sisko.sctweedie.blueyonder.co.uk> Message-ID: <35ce7f5b0606281251h2472efb2obee1432db7bbc6a0@mail.gmail.com> 2006/6/27, Stephen C. Tweedie : > > They did; try "logdump". > > It's still done at block level, but it provides some ability to browse > the log for all occurences of a given block in the log etc. > >From package description: "jfs_logdump - dump a JFS formatted device's journal log." Should it be possible to use JFS tools on ext3 filesystem? I tried it out but get an error message (perhaps will contact ibm therefore soon) jfs_logdump /dev/hdk1 jfs_logdump version 1.1.11, 05-Jun-2006 Device Name: /dev/hdk1 LOGREDO: Device is not a file system device. [logredo.c:1259] bye From zab at zabbo.net Wed Jun 28 22:50:05 2006 From: zab at zabbo.net (Zach Brown) Date: Wed, 28 Jun 2006 15:50:05 -0700 Subject: viewing ext3 journal In-Reply-To: <35ce7f5b0606281251h2472efb2obee1432db7bbc6a0@mail.gmail.com> References: <35ce7f5b0606200935p655a35a9i8b4d02dc571535dd@mail.gmail.com> <20060620181742.GV5817@schatzie.adilger.int> <35ce7f5b0606201257k816293aub8dc1120bcd61a35@mail.gmail.com> <20060620221447.GY5817@schatzie.adilger.int> <35ce7f5b0606201546n3e88102fk44ff871ac30206f3@mail.gmail.com> <20060621043510.GA5817@schatzie.adilger.int> <35ce7f5b0606211308l3b6abfecn6f2f4ab2f3e30b6f@mail.gmail.com> <1151438108.5230.29.camel@sisko.sctweedie.blueyonder.co.uk> <35ce7f5b0606281251h2472efb2obee1432db7bbc6a0@mail.gmail.com> Message-ID: <44A3079D.2020702@zabbo.net> > Should it be possible to use JFS tools on ext3 filesystem? No. Stephen was referring to the logdump command available from e2fsprog's debugfs program. Like so: # debugfs -R 'logdump /tmp/journal-dump.txt' /dev/hda1 debugfs 1.38 (30-Jun-2005) # head -4 /tmp/journal-dump.txt Journal starts at block 23374, transaction 54065 Found expected sequence 54065, type 1 (descriptor block) at block 23374 Found expected sequence 54065, type 2 (commit block) at block 23376 Found expected sequence 54066, type 1 (descriptor block) at block 23377 - z From niam.tni at googlemail.com Thu Jun 29 09:34:03 2006 From: niam.tni at googlemail.com (Stefan Drexleri) Date: Thu, 29 Jun 2006 11:34:03 +0200 Subject: viewing ext3 journal In-Reply-To: <44A3079D.2020702@zabbo.net> References: <35ce7f5b0606200935p655a35a9i8b4d02dc571535dd@mail.gmail.com> <20060620181742.GV5817@schatzie.adilger.int> <35ce7f5b0606201257k816293aub8dc1120bcd61a35@mail.gmail.com> <20060620221447.GY5817@schatzie.adilger.int> <35ce7f5b0606201546n3e88102fk44ff871ac30206f3@mail.gmail.com> <20060621043510.GA5817@schatzie.adilger.int> <35ce7f5b0606211308l3b6abfecn6f2f4ab2f3e30b6f@mail.gmail.com> <1151438108.5230.29.camel@sisko.sctweedie.blueyonder.co.uk> <35ce7f5b0606281251h2472efb2obee1432db7bbc6a0@mail.gmail.com> <44A3079D.2020702@zabbo.net> Message-ID: <35ce7f5b0606290234n390498exd065bba4f2f86445@mail.gmail.com> 2006/6/29, Zach Brown : > > No. Stephen was referring to the logdump command available from > e2fsprog's debugfs program. Like so: Don't hit me, but i tried dumb thing: # sync # perl -e 'print "B"x4000;' # sync # debugfs -R 'logdump -ac /tmp/output' /dev/hda6 # vi /tmp/output But i didn't find any patterns which look like four thousand equal characters. I guess, data will be encoded bevor written to disk. Why? How it is done? Maybe anyone can tell me quickly, how data is handled (encoded etc.) before written to disk (i know this doesn't circumvent taking a good book about filesystems/ext2 some day...) bye From adilger at clusterfs.com Thu Jun 29 09:47:07 2006 From: adilger at clusterfs.com (Andreas Dilger) Date: Thu, 29 Jun 2006 03:47:07 -0600 Subject: viewing ext3 journal In-Reply-To: <35ce7f5b0606290234n390498exd065bba4f2f86445@mail.gmail.com> References: <20060620181742.GV5817@schatzie.adilger.int> <35ce7f5b0606201257k816293aub8dc1120bcd61a35@mail.gmail.com> <20060620221447.GY5817@schatzie.adilger.int> <35ce7f5b0606201546n3e88102fk44ff871ac30206f3@mail.gmail.com> <20060621043510.GA5817@schatzie.adilger.int> <35ce7f5b0606211308l3b6abfecn6f2f4ab2f3e30b6f@mail.gmail.com> <1151438108.5230.29.camel@sisko.sctweedie.blueyonder.co.uk> <35ce7f5b0606281251h2472efb2obee1432db7bbc6a0@mail.gmail.com> <44A3079D.2020702@zabbo.net> <35ce7f5b0606290234n390498exd065bba4f2f86445@mail.gmail.com> Message-ID: <20060629094707.GZ5318@schatzie.adilger.int> On Jun 29, 2006 11:34 +0200, Stefan Drexleri wrote: > 2006/6/29, Zach Brown : > > > >No. Stephen was referring to the logdump command available from > >e2fsprog's debugfs program. Like so: > > Don't hit me, but i tried dumb thing: > > # sync > # perl -e 'print "B"x4000;' > # sync > # debugfs -R 'logdump -ac /tmp/output' /dev/hda6 > > # vi /tmp/output > > But i didn't find any patterns which look like four thousand equal > characters. > I guess, data will be encoded bevor written to disk. Why? How it is done? Data is not written to the journal normally, only metadata. Try instead to create a long filename in a directory (up to 256 chars long) and that will appear in the journal. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. From niam.tni at googlemail.com Thu Jun 29 10:42:44 2006 From: niam.tni at googlemail.com (Stefan Drexleri) Date: Thu, 29 Jun 2006 12:42:44 +0200 Subject: viewing ext3 journal In-Reply-To: <20060629094707.GZ5318@schatzie.adilger.int> References: <20060620181742.GV5817@schatzie.adilger.int> <20060620221447.GY5817@schatzie.adilger.int> <35ce7f5b0606201546n3e88102fk44ff871ac30206f3@mail.gmail.com> <20060621043510.GA5817@schatzie.adilger.int> <35ce7f5b0606211308l3b6abfecn6f2f4ab2f3e30b6f@mail.gmail.com> <1151438108.5230.29.camel@sisko.sctweedie.blueyonder.co.uk> <35ce7f5b0606281251h2472efb2obee1432db7bbc6a0@mail.gmail.com> <44A3079D.2020702@zabbo.net> <35ce7f5b0606290234n390498exd065bba4f2f86445@mail.gmail.com> <20060629094707.GZ5318@schatzie.adilger.int> Message-ID: <35ce7f5b0606290342x152bf346wfb2cda99c3f02e1@mail.gmail.com> 2006/6/29, Andreas Dilger : > > Data is not written to the journal normally, only metadata. Try instead > to create a long filename in a directory (up to 256 chars long) and that > will appear in the journal. Nice, thanks. But only 255 characters are accepted. bye