From evilninja at gmx.net Fri Oct 7 23:39:14 2005 From: evilninja at gmx.net (evilninja) Date: Sat, 08 Oct 2005 01:39:14 +0200 Subject: benchmarks galore... Message-ID: <43470722.4040408@gmx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 [cc'ing 4 mailing lists, please reply to *one* list only!] hi, every now and then i'm running some benchmarks on filesystems i really use...here are the results: http://nerdbynature.de/bench/prinz64/2.6.14-rc2-mm2/bonnie.html http://nerdbynature.de/bench/prinz64/2.6.14-rc2-mm2/ may it be of some help.... thanks, Christian. PS: reiser4 not included because of the recent compile error, i'll probably add this one. - -- BOFH excuse #197: I'm sorry a pentium won't do, you need an SGI to connect with us. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDRwciC/PVm5+NVoYRAy8FAJ4/OAdv9skHmsC5Q0fjy0+qi7HuIgCfSMQs 1EcbBrnIh21MxajBvMtVw4g= =aFUJ -----END PGP SIGNATURE----- From Richard.Wolber at boeing.com Sat Oct 8 00:19:19 2005 From: Richard.Wolber at boeing.com (EXT-Wolber, Richard) Date: Fri, 7 Oct 2005 17:19:19 -0700 Subject: Unmounted File Handle Message-ID: <8C7C41A176AC0B468BEFB2EFD9BDAB9920050B@XCH-NW-5V2.nw.nos.boeing.com> On Fri, Sep 23, 2005 at 04:11:27PM -0700, EXT-Wolber, Richard wrote: > > Is it practical to get a R/W file handle opened against an existing > > file on an unmounted ext2 filesystem? > > What do you mean by a "read/write file handle"? As you noted below, I wish to manipulate files on an unmounted filesystem. Specifically, I wish to send log messages to a file in an unmounted Filesystem. > There are a set of interfaces as part of the ext2fs library which would allow > you to manipulate a file on an unmounted filesystem. What are the cons to doing this? Performance isn't that big of an issue in our application. The whole point is to avoid mounting a filesystem in a very unfriendly environment. Power is expected to fluctuate at random intervals. It is permissible to have incomplete writes, but it is not permissable for the filesystem or files to be corrupted such that it cannot later be mounted and reviewed. What do you recommend? ..Chuck.. From puhuri at iki.fi Mon Oct 10 07:06:17 2005 From: puhuri at iki.fi (Markus Peuhkuri) Date: Mon, 10 Oct 2005 10:06:17 +0300 Subject: Unmounted File Handle In-Reply-To: <8C7C41A176AC0B468BEFB2EFD9BDAB9920050B@XCH-NW-5V2.nw.nos.boeing.com> References: <8C7C41A176AC0B468BEFB2EFD9BDAB9920050B@XCH-NW-5V2.nw.nos.boeing.com> Message-ID: <434A12E9.3040705@iki.fi> EXT-Wolber, Richard wrote: > the filesystem or files to be corrupted such that it cannot later be > mounted > Why you want to manipulate files on ext3? How about if you make a small partition and just write there without any file system. If you do like this, you can mount ext3 ro, so you do not have to worry about any corruption on "real" partition. Of course, you may need to tweak your application. -- Markus Peuhkuri | http://iki.fi/puhuri/ From sbabajan at ccpu.com Mon Oct 10 12:44:42 2005 From: sbabajan at ccpu.com (Syed Babajan) Date: Mon, 10 Oct 2005 18:14:42 +0530 Subject: how to run fsck on 500GB ext3 partition Message-ID: <22F058C3ED9D784E90CE473F2A9847F00A351A@in-exchange> -------------- next part -------------- An HTML attachment was scrubbed... URL: From evilninja at gmx.net Thu Oct 13 23:59:39 2005 From: evilninja at gmx.net (evilninja) Date: Fri, 14 Oct 2005 01:59:39 +0200 Subject: how to run fsck on 500GB ext3 partition In-Reply-To: <22F058C3ED9D784E90CE473F2A9847F00A351A@in-exchange> References: <22F058C3ED9D784E90CE473F2A9847F00A351A@in-exchange> Message-ID: <434EF4EB.2090301@gmx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 % fsck.ext3 /dev/500GB_ext3_partition ...and please don't send html mails to a mailinglist. - -- BOFH excuse #410: Electrical conduits in machine room are melting. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTvTrC/PVm5+NVoYRAwnjAJ0bHHFfOjojI7LdDwknncHZF/U+rQCdGP1Q 5eY3D/XgKk2yyTB3Poj9pTs= =If2I -----END PGP SIGNATURE----- From sr_linux at hotmail.com Wed Oct 19 20:57:16 2005 From: sr_linux at hotmail.com (sr ns) Date: Wed, 19 Oct 2005 13:57:16 -0700 Subject: EXT3 journalling issue Message-ID: Hello, I have 2 boxes with 1.5TB storage with ext3 fs, and the kernel is 2.6.11.8. I'm using E2fsprogs 1.37 for FS creation. And, Filesystem revision #: 1 (dynamic) There are 2 scenarios: 1. All SATA drives, RAID5 2. All PATA drives, RAID5 and wrapped in log volumes. I'm having lots of issues with fsck. I did search, but somehow not getting the right information. needs_recovery gets set on the file system, but FS state is clean. Can I safely ignore this? After the default number of mounts, it gets into auto fsck, and it takes hours to finish it. Isn't it supposed to do it quickly? Can I safely set the max mount count to zero? I appreciate if anyone tells me more on this. I'm very new to sys admin. Thanks.. _________________________________________________________________ Don?t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From bloch at verdurin.com Fri Oct 21 14:51:14 2005 From: bloch at verdurin.com (bloch at verdurin.com) Date: Fri, 21 Oct 2005 15:51:14 +0100 Subject: Recover original superblock on corrupted filesystem? Message-ID: <20051021145114.GA432@bloch.smith.man.ac.uk> I've been trying to use fsck to recover a corrupted filesystem. It appears the original superblock is corrupted too, as it has an inode count of 0. When I start fsck with -b 32760, it uses the alternate superblock and proceeds. However, it restarts from the beginning a couple of times and after the second restart it doesn't use the alternate superblock, stopping instead as it can't find the original one. Is there a way around this, such as using one of the alternate superblocks to replace the broken one, or a way of forcing fsck to keep on using the alternate one? The checking process is taking several hours in each case, as it's quite a large filesystem. Thanks for any suggestions. Adam From digvijoy_chatterjee at infosys.com Fri Oct 21 16:05:19 2005 From: digvijoy_chatterjee at infosys.com (Digvijoy Chatterjee) Date: Fri, 21 Oct 2005 21:35:19 +0530 Subject: Recover original superblock on corrupted filesystem? In-Reply-To: <20051021145114.GA432@bloch.smith.man.ac.uk> References: <20051021145114.GA432@bloch.smith.man.ac.uk> Message-ID: <1129910719.19799.5.camel@myshec56002d.ad.infosys.com> You could try using using mkfs -S , to just recreate the SuperBlock, check man mkfs before u do that....... take a data backup too then after superblock is recreated ...mount file system readonly..and then run fsck...once fsck has fixed the bugs....u can remount read/write..and ur fs is up and running Digz On Fri, 2005-10-21 at 15:51 +0100, bloch at verdurin.com wrote: > I've been trying to use fsck to recover a corrupted filesystem. > > It appears the original superblock is corrupted too, as it has an inode > count of 0. When I start fsck with -b 32760, it uses the alternate > superblock and proceeds. However, it restarts from the beginning a > couple of times and after the second restart it doesn't use the > alternate superblock, stopping instead as it can't find the original > one. > > Is there a way around this, such as using one of the alternate > superblocks to replace the broken one, or a way of forcing fsck to keep > on using the alternate one? The checking process is taking several > hours in each case, as it's quite a large filesystem. > > Thanks for any suggestions. > > Adam > > _______________________________________________ > Ext3-users mailing list > Ext3-users at redhat.com > https://www.redhat.com/mailman/listinfo/ext3-users **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** From adilger at clusterfs.com Mon Oct 24 19:20:40 2005 From: adilger at clusterfs.com (Andreas Dilger) Date: Mon, 24 Oct 2005 13:20:40 -0600 Subject: EXT3 journalling issue In-Reply-To: References: Message-ID: <20051024192040.GN31368@schatzie.adilger.int> On Oct 19, 2005 13:57 -0700, sr ns wrote: > needs_recovery gets set on the file system, but FS state is clean. Can I > safely ignore this? When ext3 filesystems are mounted, needs_recovery is set until they are unmounted. If e2fsck is run, or the filesystem is mounted then the journal is replayed and this flag is cleared. This prevents the need for a full e2fsck run. > After the default number of mounts, it gets into auto > fsck, and it takes hours to finish it. Isn't it supposed to do it quickly? The needs_recovery + journal makes recovery after crash go quickly. Running a full e2fsck does not go any faster with e2fsck for ext3 filesystems, but in most cases you don't need to run a full e2fsck, and this DOES go faster. > Can I safely set the max mount count to zero? Mostly, yes. There are other forms of corruption like disk, cable, memory, software that can cause errors in a filesystem. Doing periodic checks can detect these things. Setting max mount count to zero means you skip those checks until 6 months pass (which is max mount interval, and can also be tuned). Some people disable these checks because of the long e2fsck time can lenghten downtimes. In that case, you should instead schedule some time when system is down to run e2fsck for a few hours. If you are using LVM/DM you can also make a snapshot and run e2fsck -fn on it to see there are no problems, and then use tune2fs to update the "last checked" time/count. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. From sct at redhat.com Tue Oct 25 18:44:02 2005 From: sct at redhat.com (Stephen C. Tweedie) Date: Tue, 25 Oct 2005 14:44:02 -0400 Subject: Recover original superblock on corrupted filesystem? In-Reply-To: <20051021145114.GA432@bloch.smith.man.ac.uk> References: <20051021145114.GA432@bloch.smith.man.ac.uk> Message-ID: <1130265842.4965.21.camel@orbit.scot.redhat.com> Hi, On Fri, 2005-10-21 at 15:51 +0100, bloch at verdurin.com wrote: > It appears the original superblock is corrupted too, as it has an inode > count of 0. When I start fsck with -b 32760, it uses the alternate > superblock and proceeds. However, it restarts from the beginning a > couple of times and after the second restart it doesn't use the > alternate superblock, stopping instead as it can't find the original > one. Do you have a log of the fsck output, and which e2fsprogs version is this? Sounds like it may be an e2fsck bug if we don't honour the backup superblock flag on subsequent passes. > Is there a way around this, such as using one of the alternate > superblocks to replace the broken one Yes, "dd" of the appropriate block should work... but do this with extreme care, as getting it slightly wrong will cause major havoc. "debugfs" may be a better bet. # debugfs -w -b$BLOCKSIZE -s$SUPERBLOCK /dev/$DEV will tell debugfs to read the specified superblock. If you dirty the superblock (eg. with the "dirty" command) then quit, it will write back the backup superblock to the home location too. --Steph From adilger at clusterfs.com Tue Oct 25 21:17:56 2005 From: adilger at clusterfs.com (Andreas Dilger) Date: Tue, 25 Oct 2005 15:17:56 -0600 Subject: Recover original superblock on corrupted filesystem? In-Reply-To: <1130265842.4965.21.camel@orbit.scot.redhat.com> References: <20051021145114.GA432@bloch.smith.man.ac.uk> <1130265842.4965.21.camel@orbit.scot.redhat.com> Message-ID: <20051025211756.GQ31368@schatzie.adilger.int> On Oct 25, 2005 14:44 -0400, Stephen C. Tweedie wrote: > On Fri, 2005-10-21 at 15:51 +0100, bloch at verdurin.com wrote: > > It appears the original superblock is corrupted too, as it has an inode > > count of 0. When I start fsck with -b 32760, it uses the alternate > > superblock and proceeds. However, it restarts from the beginning a > > couple of times and after the second restart it doesn't use the > > alternate superblock, stopping instead as it can't find the original > > one. > > Do you have a log of the fsck output, and which e2fsprogs version is > this? Sounds like it may be an e2fsck bug if we don't honour the backup > superblock flag on subsequent passes. Actually, my thought would be that in the first pass e2fsck would grab the backup superblock and then overwrite the primary with the recovered superblock. Not 100% positive of that. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. From bloch at verdurin.com Tue Oct 25 22:05:21 2005 From: bloch at verdurin.com (bloch at verdurin.com) Date: Tue, 25 Oct 2005 23:05:21 +0100 Subject: Recover original superblock on corrupted filesystem? In-Reply-To: <1130265842.4965.21.camel@orbit.scot.redhat.com> References: <20051021145114.GA432@bloch.smith.man.ac.uk> <1130265842.4965.21.camel@orbit.scot.redhat.com> Message-ID: <20051025220521.GB17476@bloch.smith.man.ac.uk> On Tue, 25 Oct 2005, Stephen C. Tweedie wrote: > Hi, > > On Fri, 2005-10-21 at 15:51 +0100, bloch at verdurin.com wrote: > > > It appears the original superblock is corrupted too, as it has an inode > > count of 0. When I start fsck with -b 32760, it uses the alternate > > superblock and proceeds. However, it restarts from the beginning a > > couple of times and after the second restart it doesn't use the > > alternate superblock, stopping instead as it can't find the original > > one. > > Do you have a log of the fsck output, and which e2fsprogs version is > this? Sounds like it may be an e2fsck bug if we don't honour the backup > superblock flag on subsequent passes. > I do have a log, yes. It's rather large... It's version 1.38 > > Is there a way around this, such as using one of the alternate > > superblocks to replace the broken one > > Yes, "dd" of the appropriate block should work... but do this with > extreme care, as getting it slightly wrong will cause major havoc. > > "debugfs" may be a better bet. > > # debugfs -w -b$BLOCKSIZE -s$SUPERBLOCK /dev/$DEV > > will tell debugfs to read the specified superblock. If you dirty the > superblock (eg. with the "dirty" command) then quit, it will write back > the backup superblock to the home location too. > In the end I managed to get the filesystem to mount (after a six-hour fsck), backed up the data and have since wiped that partition. Thanks for the tip, though. I'll see if I can compress and/or edit the log to a sensible size. Adam From sr_linux at hotmail.com Wed Oct 26 18:57:01 2005 From: sr_linux at hotmail.com (sr ns) Date: Wed, 26 Oct 2005 11:57:01 -0700 Subject: EXT3 journalling issue In-Reply-To: <20051024192040.GN31368@schatzie.adilger.int> Message-ID: Thanks! But, I have got more issues. The fsck.ext3 takes a long time (> 90min), and sometimes it fails. I ran the debugfs and checked the journal (inode 8): ============== #/sbin/debugfs /dev/sda2 debugfs 1.35 (28-Feb-2004) debugfs: stat <8> Inode: 8 Type: regular Mode: 0600 Flags: 0x0 Generation: 0 User: 0 Group: 0 Size: 33554432 File ACL: 0 Directory ACL: 0 Links: 1 Blockcount: 65616 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x43041631 -- Thu Aug 18 05:01:37 2005 atime: 0x00000000 -- Thu Jan 1 00:00:00 1970 mtime: 0x43041631 -- Thu Aug 18 05:01:37 2005 BLOCKS: (0-11):1633-1644, (IND):1645, (12-1035):1646-2669, (DIND):2670, (IND):2671, (1036-2059):2 672-3695, (IND):3696, (2060-3083):3697-4720, (IND):4721, (3084-4107):4722-5745, (IND):574 6, (4108-5131):5747-6770, (IND):6771, (5132-6155):6772-7795, (IND):7796, (6156-7179):7797 -8820, (IND):8821, (7180-8192):8822-9834 TOTAL: 8202 ================== ================== #date Wed Oct 26 18:09:50 GMT 2005 ================== ================== #/sbin/dumpe2fs -h /dev/sda2 dumpe2fs 1.35 (28-Feb-2004) Filesystem volume name: / Last mounted on: Filesystem UUID: 22bdad74-262f-491a-ba79-a543f1900e9c Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file Default mount options: (none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 183091200 Block count: 366171553 Reserved block count: 18308577 Free blocks: 64052904 Free inodes: 183032464 First block: 0 Block size: 4096 Fragment size: 4096 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 16384 Inode blocks per group: 512 Filesystem created: Thu Aug 18 04:49:58 2005 Last mount time: Wed Oct 26 14:17:10 2005 Last write time: Wed Oct 26 14:17:10 2005 Mount count: 134 Maximum mount count: -1 Last checked: Thu Aug 18 04:49:58 2005 Check interval: 0 () Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 128 Journal inode: 8 Default directory hash: tea Directory Hash Seed: 04ee4b29-93a7-4e6c-8d34-7eaa6234dd03 Journal backup: inode blocks ================== The "mtime" (modified time?) is Aug 2005. Is there something wrong with this? Where exactly is the journal maintained? This is from a good box (with no fsck errors) - I don't have access to the affected box right now. But, it's similar to this in every way. What's the significance of "max mount count=-1"? I'm using the default rc.sysinit script of Fedora distro. Can you point me to some good doc (working details) on ext3 and journalling? Reading the code would be my last option. Sorry, I don't mean to be rude/lazy here. This is not my domain, and I'm just trying to fix this. Thanks for any advise. >From: Andreas Dilger >To: sr ns >CC: ext3-users at redhat.com >Subject: Re: EXT3 journalling issue >Date: Mon, 24 Oct 2005 13:20:40 -0600 > >On Oct 19, 2005 13:57 -0700, sr ns wrote: > > needs_recovery gets set on the file system, but FS state is clean. Can I > > safely ignore this? > >When ext3 filesystems are mounted, needs_recovery is set until they are >unmounted. If e2fsck is run, or the filesystem is mounted then the journal >is replayed and this flag is cleared. This prevents the need for a full >e2fsck run. > > > After the default number of mounts, it gets into auto > > fsck, and it takes hours to finish it. Isn't it supposed to do it >quickly? > >The needs_recovery + journal makes recovery after crash go quickly. >Running >a full e2fsck does not go any faster with e2fsck for ext3 filesystems, but >in most cases you don't need to run a full e2fsck, and this DOES go faster. > > > Can I safely set the max mount count to zero? > >Mostly, yes. There are other forms of corruption like disk, cable, memory, >software that can cause errors in a filesystem. Doing periodic checks >can detect these things. Setting max mount count to zero means you skip >those checks until 6 months pass (which is max mount interval, and can >also be tuned). Some people disable these checks because of the long >e2fsck >time can lenghten downtimes. In that case, you should instead schedule >some time when system is down to run e2fsck for a few hours. If you are >using LVM/DM you can also make a snapshot and run e2fsck -fn on it to see >there are no problems, and then use tune2fs to update the "last checked" >time/count. > >Cheers, Andreas >-- >Andreas Dilger >Principal Software Engineer >Cluster File Systems, Inc. > _________________________________________________________________ Don?t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From bunk at stusta.de Mon Oct 31 00:13:34 2005 From: bunk at stusta.de (Adrian Bunk) Date: Mon, 31 Oct 2005 01:13:34 +0100 Subject: What is the history of CONFIG_EXT{2,3}_CHECK? Message-ID: <20051031001334.GP4180@stusta.de> Can anyone tell me the history of CONFIG_EXT{2,3}_CHECK? There is code for a "check" option for mount if these options are enabled, but there's no way to enable them. TIA Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From Vince.McIntyre at atnf.csiro.au Mon Oct 31 08:33:43 2005 From: Vince.McIntyre at atnf.csiro.au (Vincent McIntyre) Date: Mon, 31 Oct 2005 19:33:43 +1100 (EST) Subject: ext3 + fs > 2Tbyte In-Reply-To: References: Message-ID: Hi list this is actually a problem on a debian system but I thought you might be interested to hear of it and perhaps can offer some help. I have a woody box (dell pe750, dual cpu) running a kernel from backports.org (debian 'testing' packages built on a 'stable' box). The kernel version is 2.6.7-1.backports.org.1. This host is hooked up to an Apple Xserve RAID with a 2.3Tbyte ptn that was created by the same system that is now giving trouble. My problem is that mount (2.12-4.backports.org.1) fails to mount this partition. It worked fine before, but stopped working after a power outage. Before I was using mount version 2.11n-7woody1 (the stock debian 'woody' version). I upgraded to the backports.org version of mount after this problem appeared, but it didn't help. The symptom is - # mount /dev/sdb1 mount: wrong fs type, bad option, bad superblock on /dev/sdb1, or too many mounted file systems (aren't you trying to mount an extended partition, instead of some logical partition inside?) My question to you is: where to look for help, if not here. Do I need to upgrade mount? fdisk? Am I missing a kernel module? I did a grep through the kernel-doc-2.6.7 tree for EFI and GPT and didn't find much information relevant to this problem. Thanks Vince More information ---------------- The filesystem is ext3 but I don't have a note of the command used to create it. I do have the ext3 module loaded. This filesystem is just data, it's not a booting issue. In fact I've commented the fstab entry out so I can get a clean boot, and am now trying to mount the fs on a fully running system. I uncommented the entry after boot. The fstab entry looks like this # /dev/sdb1 /export/archive01 ext3 defaults 0 2 To get this large a partition, I was forced to partition with a self-built parted (1.6.19, which supports using a gpt disk label). This worked ok, and parted still seems happy with the partition: # /local/sbin/parted /dev/sdb print Disk geometry for /dev/sdb: 0.000-2289288.000 megabytes Disk label type: gpt Minor Start End Filesystem Name Flags 1 0.017 2289287.983 ext3 Information: Don't forget to update /etc/fstab, if necessary. Fdisk is not entirely happy however. (util-linux, 2.12-4.backports.org) # fdisk -l /dev/sdb You must set cylinders. You can do this from the extra functions menu. Disk /dev/sdb: 0 MB, 0 bytes 255 heads, 63 sectors/track, 0 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdb1 1 267350 2147483647+ ee EFI GPT Partition 1 has different physical/logical beginnings (non-Linux?): phys=(0, 0, 1) logical=(0, 0, 2) Partition 1 has different physical/logical endings: phys=(1023, 254, 63) logical=(267349, 89, 4) Nor is e2fsprogs (1.35-5.backports.org.1) # e2fsck /dev/sdb1 e2fsck 1.35 (28-Feb-2004) Couldn't find ext2 superblock, trying backup blocks... e2fsck: Bad magic number in super-block while trying to open /dev/sdb1 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 Trying e2fsck -b 8193 /dev/sdb1 gives the same result. # tune2fs -l /dev/sdb1 tune2fs 1.35 (28-Feb-2004) tune2fs: Bad magic number in super-block while trying to open /dev/sdb1 Couldn't find valid filesystem superblock. I tried turning on EFI_PARTITION in the kernel and rebuilding. This doesn't help, the kernel just wedges itself during the boot, shortly after starting kjournald and mounting the ext3 partitions on the boot disk, /dev/sda (a 73GB scsi disk). From alex at alex.org.uk Mon Oct 31 09:01:50 2005 From: alex at alex.org.uk (Alex Bligh) Date: Mon, 31 Oct 2005 09:01:50 +0000 Subject: 1.5TB ext3 partitions - mke2fs problems at 2^31 blocks Message-ID: <60C5C4BDECE0B72DC80D04A6@[192.168.100.25]> I am trying to get a 9550SX to support a 1.5TB raid partition. I am unsure whether this is a driver problem, or an ext3 problem (as am getting some other wierdness detecting LUNs), but... fdisk recognizes the disk OK. I make a single extended partition with a single 1.5TB logical partition inside it. I then run mke2fs -j /dev/sdb It gets to writing inode tables, and wants to write 11176 block groups. It gets to 3600 (odd) of 11176 block groups fine, then slows to a complete crawl (2 secs per write), though strace shows it is fine. My suspicious mind says this is 1/3 of the way through the disk, which is 2^31 blocks, i.e. where the block number goes negative in a signed environment. Is there a problem with ext3 supporting more than 2^31 blocks? System: AMD64 2 x Opteron 275 Ubuntu Breezy mke2fs 1.38 Kernel 2.6.12 + 3w9xxx from 2.6.14 or from 3-ware 3-ware 9550SX RAID controller, latest firmware, BIOS RAID-5 1.5 TB single partition disk Alex From alex at alex.org.uk Mon Oct 31 09:38:49 2005 From: alex at alex.org.uk (Alex Bligh) Date: Mon, 31 Oct 2005 09:38:49 +0000 Subject: 1.5TB ext3 partitions - mke2fs problems at 2^31 blocks In-Reply-To: <60C5C4BDECE0B72DC80D04A6@[192.168.100.25]> References: <60C5C4BDECE0B72DC80D04A6@[192.168.100.25]> Message-ID: > I am trying to get a 9550SX to support a 1.5TB raid partition. I am unsure > whether this is a driver problem, or an ext3 problem (as am getting some > other wierdness detecting LUNs), but... I forgot to say, I think the underlying disk is OK and is not aliasing. I tried Stephen Tweedie's verify-data and it seems to be OK (I am taking it the error can, as it claims, be ignored). The same happens if I run it to /dev/sdb5. Furthermore, mkfs -treiserfs seems to run OK (though it takes a couple of minutes). So I am beginning to think this is ext3 (or ext3 tools) related. Alex amb at polonius:~/verify-data/verify-data-0.7$ sudo ./verify-data /dev/sdb 8G File is a block device: size 1499968045056 bytes (1.36T) Writing for 1.00M bytes every 8.00G bytes writing block 175 [offset 1.37T]...... Error writing file at offset 1503238553600 (1.37T): No space left on device (EOF, ignored) Completed writing file with 0 errors. Rereading for 1.00M bytes every 8.00G bytes reading block 174 [offset 1.36T]...... Completed reading file with 0 errors. amb at polonius:~/verify-data/verify-data-0.7$ sudo ./verify-data -S /dev/sdb 8G File is a block device: size 1499968045056 bytes (1.36T) Writing for 1.00M bytes every 8.00G bytes writing block 175 [offset 1.37T]...... Error writing file at offset 1503238553600 (1.37T): No space left on device (EOF, ignored) Completed writing file with 0 errors. Rereading for 1.00M bytes every 8.00G bytes reading block 174 [offset 1.36T]...... Completed reading file with 0 errors. amb at polonius:~/verify-data/verify-data-0.7$ sudo ./verify-data -F /dev/sdb 8G File is a block device: size 1499968045056 bytes (1.36T) Writing for 1.00M bytes every 8.00G bytes writing block 175 [offset 1.37T]...... Error writing file at offset 1503238553600 (1.37T): No space left on device (EOF, ignored) Completed writing file with 0 errors. Rereading for 1.00M bytes every 8.00G bytes reading block 174 [offset 1.36T]...... Completed reading file with 0 errors. From adilger at clusterfs.com Mon Oct 31 21:25:03 2005 From: adilger at clusterfs.com (Andreas Dilger) Date: Mon, 31 Oct 2005 14:25:03 -0700 Subject: What is the history of CONFIG_EXT{2,3}_CHECK? In-Reply-To: <20051031001334.GP4180@stusta.de> References: <20051031001334.GP4180@stusta.de> Message-ID: <20051031212503.GY31368@schatzie.adilger.int> On Oct 31, 2005 01:13 +0100, Adrian Bunk wrote: > Can anyone tell me the history of CONFIG_EXT{2,3}_CHECK? > > There is code for a "check" option for mount if these options are > enabled, but there's no way to enable them. These are expensive debugging options, which walk the inode/block bitmaps for getting the group inode/block usage instead of using the group summary data. Not used very often but I suspect occasionally useful for developers mucking with ext[23] internals. Since it is developer-only code it needs to be enabled with #define CONFIG_EXT[23]_CHECK in a header or compile option. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. From adilger at clusterfs.com Mon Oct 31 22:02:17 2005 From: adilger at clusterfs.com (Andreas Dilger) Date: Mon, 31 Oct 2005 15:02:17 -0700 Subject: 1.5TB ext3 partitions - mke2fs problems at 2^31 blocks In-Reply-To: <60C5C4BDECE0B72DC80D04A6@[192.168.100.25]> References: <60C5C4BDECE0B72DC80D04A6@[192.168.100.25]> Message-ID: <20051031220217.GB31368@schatzie.adilger.int> On Oct 31, 2005 09:01 +0000, Alex Bligh wrote: > I am trying to get a 9550SX to support a 1.5TB raid partition. I am unsure > whether this is a driver problem, or an ext3 problem (as am getting some > other wierdness detecting LUNs), but... > > fdisk recognizes the disk OK. I make a single extended partition with a > single 1.5TB logical partition inside it. I then run > > mke2fs -j /dev/sdb > > It gets to writing inode tables, and wants to write 11176 block groups. > It gets to 3600 (odd) of 11176 block groups fine, then slows to a complete > crawl (2 secs per write), though strace shows it is fine. > > My suspicious mind says this is 1/3 of the way through the disk, which is > 2^31 blocks, i.e. where the block number goes negative in a signed > environment. > > Is there a problem with ext3 supporting more than 2^31 blocks? We have customers using partitions close to 2TB, with 2.4.21 RHEL3, 2.6.5 SLES9, 2.6.9 RHEL4. It is concievable that your SCSI card/driver is not doing proper cache after 1TB or somehow starting to do strange things with the PCI bus after that point. Try doing something like: dd if=/dev/zero of=/dev/sdb bs=1M & sleep 1; while killall -USR1 dd; sleep 1; done and then plot the dd progress vs time to see if the rate is dramatically different over time. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. From adilger at clusterfs.com Mon Oct 31 22:06:48 2005 From: adilger at clusterfs.com (Andreas Dilger) Date: Mon, 31 Oct 2005 15:06:48 -0700 Subject: ext3 + fs > 2Tbyte In-Reply-To: References: Message-ID: <20051031220648.GC31368@schatzie.adilger.int> On Oct 31, 2005 19:33 +1100, Vincent McIntyre wrote: > This host is hooked up to an Apple Xserve RAID with a 2.3Tbyte ptn > that was created by the same system that is now giving trouble. > > My problem is that mount (2.12-4.backports.org.1) fails to mount this > partition. It worked fine before, but stopped working after a power > outage. Before I was using mount version 2.11n-7woody1 (the stock debian > 'woody' version). I upgraded to the backports.org version of mount after > this problem appeared, but it didn't help. > > The symptom is - > # mount /dev/sdb1 > mount: wrong fs type, bad option, bad superblock on /dev/sdb1, > or too many mounted file systems > (aren't you trying to mount an extended partition, > instead of some logical partition inside?) It sounds like you have overflowed the end of the 2TB device limit and clobbered the beginning of your filesystem. This can happen if the SCSI driver, kernel, or even ext3 isn't handling offsets > 2^31 properly. I know RH has only recently started supporting ext3 filesystems > 2TB, and it isn't clear that all drivers handle this properly yet. > # e2fsck /dev/sdb1 > e2fsck 1.35 (28-Feb-2004) > Couldn't find ext2 superblock, trying backup blocks... > e2fsck: Bad magic number in super-block while trying to open /dev/sdb1 > > 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 > > Trying e2fsck -b 8193 /dev/sdb1 gives the same result. Please update your e2fsprogs to the latest. You also need to use "e2fsck -b 32768" (or multiple thereof) for such large filesystems. I think newer e2fsprogs will print this message properly in that case. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. From menscher at uiuc.edu Mon Oct 31 22:10:48 2005 From: menscher at uiuc.edu (Damian Menscher) Date: Mon, 31 Oct 2005 16:10:48 -0600 (CST) Subject: 1.5TB ext3 partitions - mke2fs problems at 2^31 blocks In-Reply-To: <60C5C4BDECE0B72DC80D04A6@[192.168.100.25]> References: <60C5C4BDECE0B72DC80D04A6@[192.168.100.25]> Message-ID: On Mon, 31 Oct 2005, Alex Bligh wrote: > mke2fs -j /dev/sdb > > My suspicious mind says this is 1/3 of the way through the disk, which is > 2^31 blocks, i.e. where the block number goes negative in a signed > environment. > > Is there a problem with ext3 supporting more than 2^31 blocks? > > System: > AMD64 2 x Opteron 275 > Ubuntu Breezy > mke2fs 1.38 > Kernel 2.6.12 + 3w9xxx from 2.6.14 or from 3-ware > 3-ware 9550SX RAID controller, latest firmware, BIOS > RAID-5 1.5 TB single partition disk FWIW, we've been running a 3.5T partition for about a year, on x86_64-smp FC4. We had to compile the latest parted to create the GPT partition table, but other than that it wasn't a big problem. I can say that we had serious problems getting a >2TB partition working with a 32-bit machine, or a 2.4 kernel. Those are the problems that Andreas just referenced in his message in the other thread. :) I don't remember for sure whether we're actually USING more than 2TB of the 3.5 right now (and the machine is down today so I can't check). Damian Menscher -- -=#| www.uiuc.edu/~menscher/ Ofc:(650)273-2757 |#=- -=#| The above opinions are not necessarily those of my employers. |#=-