On Sun, 2009-07-26 at 13:57 -0700, [email protected] wrote: > Upon returning from a short vacation and powering my system back on I > neglected to check the video connection and powered the system off > thinking it failed to boot. After discovering the true cause of the > problem Linux Mint was giving errors on accessing my data partition on > boot. Booting from a live CD and runnning "sudo jfs_fsck > -avpf /dev/sda7" now produces this result: > > jfs_fsck version 1.1.12, 24-Aug-2007 > processing started: 7/26/2009 15.9.36 > The current device is: /dev/sda7 > Open(...READ/WRITE EXCLUSIVE...) returned rc = 0 > Primary superblock is valid. > The type of file system for the device is JFS. > Block size in bytes: 4096 > Filesystem size in blocks: 233307970 > **Phase 0 - Replay Journal Log > LOGREDO: Allocating for ReDoPage: (d) 4096 bytes > LOGREDO: Allocating for NoDoFile: (d) 4096 bytes > LOGREDO: Allocating for BMap: (d) 480752 bytes > LOGREDO: Allocating for IMap: (d) 22336 bytes > LOGREDO: Log record for Sync Point at: 0x0dd7d7c > LOGREDO: Beginning to update the Inode Allocation Map. > LOGREDO: Done updating the Inode Allocation Map. > LOGREDO: Beginning to update the Block Map. > ujfs_rw_diskblocks: read 0 of 4096 bytes at offset 23048192 > LOGREDO: Read Block Map data extents failed. > LOGREDO: Write Block Map control page failed in UpdateMaps(). > LOGREDO: Unable to update map(s). > logredo failed (rc=-271). fsck continuing. > **Phase 1 - Check Blocks, Files/Directories, and Directory Entries > **Phase 2 - Count links > **Phase 3 - Duplicate Block Rescan and Directory Connectedness > **Phase 4 - Report Problems > **Phase 5 - Check Connectivity > **Phase 6 - Perform Approved Corrections > **Phase 7 - Rebuild File/Directory Allocation Maps > **Phase 8 - Rebuild Disk Allocation Maps > ujfs_rw_diskblocks: read 8192 of 16384 bytes at offset 23040000 > Unrecoverable error reading M from /dev/sda7. CANNOT CONTINUE. > Fatal error (-10093,30) accessing the filesystem (1,23040000,16384,16384). > **** Filesystem was modified. **** > processing terminated: 7/26/2009 15:16:35 with return code: -10093 exit > code: 4. > > Unfortunately googling for a solution resulted in only about six hits; > two of which appear to be approximately the same as my problem, > however I see no actual resolution to the problem either in the 2005 > or the 2008 reported cases. Is there a solution to this problem yet?
The reported I/O errors are both near the end of the partition. It looks as if the system thinks the partition is smaller than jfs thinks it is. Could something have happened to the partition definition? > > Even if it were possible to access most of the data by mounting read > only, I can't even recover my data to another drive at the moment > because I have not yet come up with the financial resources to > purchase another terabyte drive for backup purposes. I am quite > nervous at this point regarding my data. Can the partition be > repaired or is the only option to copy all accessible data to another > partition and reformat? Is there any way to find out exactly what > data is in the blocks affected and if so and the data is determined to > be inconsequential, can the problem be cleared up by deleting or > overwriting the blocks? You really should have some way of backing up any important data. I know this can be a challenge with a terabyte of data, but bad things sometimes happen. If it turns out that the partition shows up to be smaller than 233307970 4096-byte blocks, it may be possible to fix it with fdisk, parted, or something. I'm not sure the safest way to do this, and if your data isn't backed up, I'd be very careful about that. If the size of the partition isn't the problem, do you see any I/O errors in dmesg output? Shaggy -- David Kleikamp IBM Linux Technology Center ------------------------------------------------------------------------------ _______________________________________________ Jfs-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jfs-discussion
