I just ran into this, similar to a post I had seen from ~Dec 14 2007.
Bummer for me is, it crashed my machine - I cannot login after reboot. fsck reported several errors that flew by way too fast to catch, and rebooted. Afterwards, it boots, but I cannot login, single or multi user. Tells me 'invalid login' for all users that had existed.
We had just put a couple hundred MB onto the disks via scp, when the error appeared in syslog.
running jfs 1.11, kernel 2.6.23.1 x86_64, with paravirtualzation on, in vmware server 2.0 beta.
Host machine is a dual opteron, running the VM disks on a ciprico (broadcom) 4452, attached to 4 seagate 300GB drives in RAID5.
I have another image of this vm, i am going to try and downgrade to vmware server 1.0.4 and run again, to see if there is any difference.
I am glad to collect information from the b0rked drive, I will boot a cd iso, so if you can tell me what info to collect, I will supply it.
As an alternative, I might be able to ship you the VM...
Logged In: YES
user_id=422440
Originator: NO
This error shows up every once in a while, but I've never been able to track down the root cause. There might be more than one.
Since fsck obviously "fixed" a lot of problems on the disk, I'm not sure if the disk image would be very helpful. About the only thing that might help is the log (not the journal) that fsck creates when running.
Can you run "jfs_fscklog -e /dev/???" and "jfs_fscklog -p -e /dev/???" and send me fscklog.old and fscklog.new? You can mail them to shaggy@linux.vnet.ibm.com.
I'm assuming you were able to recover any data that you needed
Thanks,
Shaggy
Logged In: YES
user_id=1488557
Originator: YES
hmm - looks like I cannot send those, here is what I get when I try:
fjs_fscklog version 1.1.11, 05-Jun-2006
ujfs_rw_diskblocks: read 0 of 4096 bytes at offset 32768
Unable to read primary superblock. [extract.c:944]
Primary superblock is corrupt. [extract.c:953]
ujfs_rw_diskblocks: read 0 of 4096 bytes at offset 61440
Unable to read secondary superblock. [extract.c:959]
Secondary superblock is corrupt. [extract.c:970]
XCHKLOG fsck service log selected: MOST RECENT [extract.c:468]
fjs_fscklog version 1.1.11, 05-Jun-2006
ujfs_rw_diskblocks: read 0 of 4096 bytes at offset 32768
Unable to read primary superblock. [extract.c:944]
Primary superblock is corrupt. [extract.c:953]
ujfs_rw_diskblocks: read 0 of 4096 bytes at offset 61440
Unable to read secondary superblock. [extract.c:959]
Secondary superblock is corrupt. [extract.c:970]
XCHKLOG fsck service log selected: PREVIOUS [extract.c:470]
I have not yet tried to copy off my data, as I didn't want to disturb anything useful. I can see it, at least, so I am gonna spin up another drive, format ext3, and try and get it off.
Thanks,
David
Logged In: YES
user_id=422440
Originator: NO
That's a lot worse than I expected. Are you able to mount the file system readonly? This would let you copy off any data still accessible without risking further damage.
Logged In: YES
user_id=1488557
Originator: YES
I am creating an ext3 version of that drive right now, I will let you know if I get it all back. Mounting readonly does appear to work, we will see if things got scrambled or not here in a bit.
Luckily, nothing was put onto that drive that I cannot duplicate from other sources.
*crosses fingers*
Logged In: YES
user_id=422440
Originator: NO
I took a closer look at the jfs_fscklog output. It's not reading the drive at all:
ujfs_rw_diskblocks: read 0 of 4096 bytes at offset 32768
This can't be due to filesystem corruption. Could you double-check that the device is readable, and that the command was run correctly?
It's a rarely run command, so maybe there is some stupid bug that I don't see on an x86 system. I can play with it on an x86_64 system to give it a sanity check.
Dear All,
I am experimentig same big troubles, on my sarver i had this errors:
Nov 3 14:11:41 StorageServer kernel: ERROR: (device dm-0): diRead: i_ino != di_number
Nov 3 14:11:42 StorageServer last message repeated 9 times
Nov 3 14:14:14 StorageServer kernel: ERROR: (device dm-0): diRead: i_ino != di_number
Nov 3 14:14:14 StorageServer last message repeated 9 times
Nov 3 14:16:05 StorageServer last message repeated 10 times
Nov 3 14:36:30 StorageServer kernel: ERROR: (device dm-0): diRead: i_ino != di_number
Nov 3 14:36:30 StorageServer last message repeated 5 times
Nov 3 14:37:04 StorageServer kernel: ERROR: (device dm-0): DT_GETPAGE: dtree page corrupt
Nov 3 14:37:04 StorageServer last message repeated 5 times
I have created this filesystem 2 week ago and it is a JFS filesystem created on top of 6,4 TB LVM volume, composed of a single raid6 volume made with an hardware adaptec raid (kernel recognizes it as "aacraid").
Kernel is a Debian 2.6.24-etchnhalf.1-amd64 , and it is running on Sun X4150 dual quad-core xeon and 32gb ram.
I have runned a jfs_sfsck /dev/vg01/lvol0, but it has caused a lost of entire directory tree.
Do you think could be a JFS itself or can be something else ?
Reconsidering to configure more than one raid array into two or three smaller and then, involving them in an unique lvm, could be more reliable solution ?
Thanks a lot.
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs"
I can probably help with debugging this issue. I have a bunch of embedded machines running JFS utils 1.1.11 and I have been seeing this issue A LOT.
Greetings from Los angeles! I'm bored to tears at work so I decided to browse your website on my iphone during lunch break. I love the information you present here and can't wait to take a look when I get home. I'm amazed at how fast your blog loaded on my phone .. I'm not even using WIFI, just 3G .. Anyways, amazing site!
north face jackets for women http://tesrdhngnb.bloghi.com/2012/11/12/north-face-jackets-clearance-which-sa-lzer-equates-to-the-growth-of-shanghai.html
This design is wicked! You obviously know how to keep a reader entertained. Between your wit and your videos, I was almost moved to start my own blog (well, almost...HaHa!) Wonderful job. I really enjoyed what you had to say, and more than that, how you presented it. Too cool!
cheap north face http://www.hotselldenalijacketsclearance.org/2012/11/17/cheap-north-faceone/