Re: Possible bug in mkfs.ext3
Andreas Dilger <[email protected]> Sat, 20 Sep 2014 00:07:30 -0600
| Newsgroups | gmane.comp.file-systems.ext3.user |
|---|---|
| Message-ID | <[email protected]> |
--===============3849121833055630556== Content-Type: multipart/signed; boundary="Apple-Mail=_069E1DA9-DBAF-49DB-856C-1D9B01C42DAE"; protocol="application/pgp-signature"; micalg=pgp-sha1 --Apple-Mail=_069E1DA9-DBAF-49DB-856C-1D9B01C42DAE Content-Type: multipart/mixed; boundary="Apple-Mail=_4A84673D-EDB1-4F14-8676-018C0B8C257B" --Apple-Mail=_4A84673D-EDB1-4F14-8676-018C0B8C257B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 19, 2014, at 7:56 PM, jd1008 <[email protected]> wrote: > I am reporting this on the advice of the Fedora Users Mailing List = Member. >=20 > This the mailing list exchange outlining the problem with specifying = -S to mkfs, and it's subsequent consequences when fsck is run. >=20 > I am reporting this per suggestions made to me on the Fedora Users = Mailing List. I would say that "mke2fs -S" is going to lead to worse corruption rather than improving the situation in 999 times of 1000. It should only be used by someone who knows very specific details of the filesystem and how it was corrupted. I'm tempted to make it an "undocumented" feature, since I suspect it will do more harm than good in most cases. "-S" should at least call check_plausibility() and proceed_question() before clobbering the filesystem. Better would be something like the "findsuper" utility in the e2fsprogs sources (attached here for your conveniece). Usually in cases like this the problem is actually something with the partition table, and not that all of your backup superblocks have mysteriously been corrupted at the same time. Cheers, Andreas > The following is the mailing list exchange: >=20 >=20 > On 09/18/2014 07:01 PM, Robert Nichols wrote: >> On 09/18/2014 12:37 PM, jd1008 wrote: >>> Is there any other tool that can extract files from a partition that >>> seems to have corrupted superblocks? >>> I tried dumpe2fs, and fsck -b <blockNumber> >>> to no avail. Tried all available block numbers that are listed >>> when original mkfs was done, and it's output was saved. >>>=20 >>> None of the blocks seem to work - all of them have invalid magic. >>=20 >> Verify that the partition table still appears to be correct. If it >> is pointing to the wrong starting location, none of the super blocks >> will appear in the expected places. You might see if /testdisk/can >> find any intact super blocks. >>=20 >> Consider using a hex editor to look at some of the super blocks. >> They should contain the same data. The data that actually appears >> there might give some clue as to what happened. >>=20 >> As a last ditch recovery effort, run mke2fs/mke3fs with the "-S" >> option to initialize the super blocks and group descriptors only. >> Do this only with (or on) a backup copy of the partition, since >> it is potentially destructive. Then see if /debugfs/can make >> sense of the filesystem, and if so, run /fsck/with the "-f" >> option to repair the metadata.=20 >=20 >=20 > On 09/19/2014 07:16 PM, Chris Murphy wrote: >> On Sep 19, 2014, at 11:49 AM, jd1008 <[email protected]> wrote: >>=20 >>> On 09/19/2014 08:39 AM, Robert Nichols wrote: >>>> On 09/18/2014 10:57 PM, jd1008 wrote: >>>>> I ran mkfs.ext3 -S /dev/sdc7 >>>>> then ran fsck.ext3 -y /dev/sdc7 >>>>> it blew away EVERYTHING :) >>>>>=20 >>>>> Back to square one and re-dd original to test drive >>>>> and start over. >>>> Ouch! That _used_ to work. Trying it just now, "mke3fs -S" seems >>>> to clear a substantial portion of the inodes, which the manpage >>>> specifically says it should _not_ do, and then /fsck/ completes the >>>> destruction by moving all of the remaining inodes to lost+found. >>>>=20 >>>> Sorry about that. >>>>=20 >>> Can raise a bug against it? >> Chances are this is an upstream bug, or a misunderstanding. You = should post your reproduce steps to the ext4 list, what you expect to = happen based on man page, and what actually happens. >> http://vger.kernel.org/vger-lists.html#linux-ext4 >>=20 >>=20 >> Chris Murphy >=20 > _______________________________________________ > Ext3-users mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/ext3-users Cheers, Andreas --Apple-Mail=_4A84673D-EDB1-4F14-8676-018C0B8C257B Content-Disposition: attachment; filename=findsuper.c Content-Type: application/octet-stream; name="findsuper.c" Content-Transfer-Encoding: 7bit /* * findsuper --- quick hacked up program to find ext2 superblocks. * * This is a hack, and really shouldn't be installed anywhere. If you * need a program which does this sort of functionality, please try * using gpart program. * * Portions Copyright 1998-2000, Theodore Ts'o. * * Well, here's my linux version of findsuper. * I'm sure you coulda done it faster. :) * IMHO there isn't as much interesting data to print in the * linux superblock as there is in the SunOS superblock--disk geometry is * not there...and linux seems to update the dates in all the superblocks. * SunOS doesn't ever touch the backup superblocks after the fs is created, * as far as I can tell, so the date is more interesting IMHO and certainly * marks which superblocks are backup ones. * * I wanted to add msdos support, but I couldn't make heads or tails * of the kernel include files to find anything I could look for in msdos. * * Reading every block of a Sun partition is fairly quick. Doing the * same under linux (slower hardware I suppose) just isn't the same. * It might be more useful to default to reading the first (second?) block * on each cyl; however, if the disk geometry is wrong, this is useless. * But ya could still get the cyl size to print the numbers as cyls instead * of blocks... * * run this as (for example) * findsuper /dev/hda * findsuper /dev/hda 437760 1024 (my disk has cyls of 855*512) * * I suppose the next step is to figgure out a way to determine if * the block found is the first superblock somehow, and if so, build * a partition table from the superblocks found... but this is still * useful as is. * * Steve * [email protected] * [email protected] * * Additional notes by Andreas Dilger <[email protected]>: * - fixed to support > 2G devices by using lseek64 * - add reliability checking for the superblock to avoid random garbage * - add adaptive progress meter * * It _should_ also handle signals and tell you the ending block, so * that you can resume at a later time, but it doesn't yet... * * Note that gpart does not appear to find all superblocks that aren't aligned * with the start of a possible partition, so it is not useful in systems * with LVM or similar setups which don't use fat partition alignment. * * %Begin-Header% * This file may be redistributed under the terms of the GNU Public * License. * %End-Header% */ /* * Documentation addendum added by Andreas [email protected]/[email protected] * * The program findsuper is a utility that scans a disk and finds * copies of ext2 superblocks (by checking for the ext2 signature). * * For each superblock found, it prints the offset in bytes, the * offset in 1024-byte blocks, the size of the ext2 partition in fs * blocks, the filesystem blocksize (in bytes), the block group number * (always 0 for older ext2 systems), and a timestamp (s_mtime). * * This program can be used to retrieve partitions that have been * lost. The superblock for block group 0 is found 1 block (2 * sectors) after the partition start. * * For new systems that have a block group number in the superblock it * is immediately clear which superblock is the first of a partition. * For old systems where no group numbers are given, the first * superblock can be recognised by the timestamp: all superblock * copies have the creation time in s_mtime, except the first, which * has the last time e2fsck or tune2fs wrote to the filesystem. * */ #define _FILE_OFFSET_BITS 64 #include "config.h" #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <errno.h> #include <fcntl.h> #include <time.h> #include "ext2fs/ext2_fs.h" #include "ext2fs/ext2fs.h" #include "nls-enable.h" #undef DEBUG #ifdef DEBUG #define WHY(fmt, arg...) { printf("\r%Ld: " fmt, sk, ##arg) ; continue; } #else #define WHY(fmt, arg...) { continue; } #endif static void usage(void) { fprintf(stderr, _("Usage: findsuper device [skipbytes [startkb]]\n")); exit(1); } int main(int argc, char *argv[]) { int skiprate=512; /* one sector */ loff_t sk=0, skl=0; int fd; char *s; time_t tm, last = time(0); loff_t interval = 1024 * 1024; int c, print_jnl_copies = 0; const char * device_name; struct ext2_super_block ext2; /* interesting fields: EXT2_SUPER_MAGIC * s_blocks_count s_log_block_size s_mtime s_magic s_lastcheck */ #ifdef ENABLE_NLS setlocale(LC_MESSAGES, ""); setlocale(LC_CTYPE, ""); bindtextdomain(NLS_CAT_NAME, LOCALEDIR); textdomain(NLS_CAT_NAME); set_com_err_gettext(gettext); #endif while ((c = getopt (argc, argv, "j")) != EOF) { switch (c) { case 'j': print_jnl_copies++; break; default: usage(); } } if (optind == argc) usage(); device_name = argv[optind++]; if (optind < argc) { skiprate = strtol(argv[optind], &s, 0); if (s == argv[optind]) { fprintf(stderr,_("skipbytes should be a number, not %s\n"), s); exit(1); } optind++; } if (skiprate & 0x1ff) { fprintf(stderr, _("skipbytes must be a multiple of the sector size\n")); exit(2); } if (optind < argc) { sk = skl = strtoll(argv[optind], &s, 0) << 10; if (s == argv[optind]) { fprintf(stderr, _("startkb should be a number, not %s\n"), s); exit(1); } optind++; } if (sk < 0) { fprintf(stderr, _("startkb should be positive, not %llu\n"),sk); exit(1); } fd = open(device_name, O_RDONLY); if (fd < 0) { perror(device_name); exit(1); } /* Now, go looking for the superblock! */ printf(_("starting at %llu, with %u byte increments\n"), sk, skiprate); if (print_jnl_copies) printf(_("[*] probably superblock written in the ext3 " "journal superblock,\n\tso start/end/grp wrong\n")); printf(_("byte_offset byte_start byte_end fs_blocks blksz grp last_mount_time sb_uuid label\n")); for (; lseek64(fd, sk, SEEK_SET) != -1 && read(fd, &ext2, 512) == 512; sk += skiprate) { static unsigned char last_uuid[16] = "blah"; unsigned long long bsize, grpsize; int jnl_copy, sb_offset; if (sk && !(sk & (interval - 1))) { time_t now, diff; now = time(0); diff = now - last; if (diff > 0) { s = ctime(&now); s[24] = 0; printf("\r%11Lu: %8LukB/s @ %s", sk, (((sk - skl)) / diff) >> 10, s); fflush(stdout); } if (diff < 5) interval <<= 1; else if (diff > 20) interval >>= 1; last = now; skl = sk; } if (ext2.s_magic != EXT2_SUPER_MAGIC) continue; if (ext2.s_log_block_size > 6) WHY("log block size > 6 (%u)\n", ext2.s_log_block_size); if (ext2fs_r_blocks_count(&ext2) > ext2fs_blocks_count(&ext2)) WHY("r_blocks_count > blocks_count (%u > %u)\n", ext2fs_r_blocks_count(&ext2), ext2fs_blocks_count(&ext2)); if (ext2fs_free_blocks_count(&ext2) > ext2fs_blocks_count(&ext2)) WHY("free_blocks_count > blocks_count\n (%u > %u)\n", ext2fs_free_blocks_count(&ext2), ext2fs_blocks_count(&ext2)); if (ext2.s_free_inodes_count > ext2.s_inodes_count) WHY("free_inodes_count > inodes_count (%u > %u)\n", ext2.s_free_inodes_count, ext2.s_inodes_count); tm = ext2.s_mtime; s = ctime(&tm); s[24] = 0; bsize = 1 << (ext2.s_log_block_size + 10); grpsize = bsize * ext2.s_blocks_per_group; if (memcmp(ext2.s_uuid, last_uuid, sizeof(last_uuid)) == 0 && ext2.s_rev_level > 0 && ext2.s_block_group_nr == 0) { jnl_copy = 1; } else { jnl_copy = 0; memcpy(last_uuid, ext2.s_uuid, sizeof(last_uuid)); } if (ext2.s_block_group_nr == 0 || bsize == 1024) sb_offset = 1024; else sb_offset = 0; if (jnl_copy && !print_jnl_copies) continue; printf("\r%11Lu %11Lu%s %11Lu%s %9u %5Lu %4u%s %s %02x%02x%02x%02x %s\n", sk, sk - ext2.s_block_group_nr * grpsize - sb_offset, jnl_copy ? "*":" ", sk + ext2fs_blocks_count(&ext2) * bsize - ext2.s_block_group_nr * grpsize - sb_offset, jnl_copy ? "*" : " ", ext2fs_blocks_count(&ext2), bsize, ext2.s_block_group_nr, jnl_copy ? "*" : " ", s, ext2.s_uuid[0], ext2.s_uuid[1], ext2.s_uuid[2], ext2.s_uuid[3], ext2.s_volume_name); } printf(_("\n%11Lu: finished with errno %d\n"), sk, errno); close(fd); return errno; } --Apple-Mail=_4A84673D-EDB1-4F14-8676-018C0B8C257B Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_4A84673D-EDB1-4F14-8676-018C0B8C257B-- --Apple-Mail=_069E1DA9-DBAF-49DB-856C-1D9B01C42DAE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVB0Zo3Kl2rkXzB/gAQJEMw/+LWndJEm0pWteGaMA9OEt7Iy4TPfe7kkQ DqnoXwamfxZKE3TbMmq/6kYpITm5GIVcFP+g0wWc0J4fW5gfqUOlS7h8yzCAWctQ OlPTd150xZPvf2qvrGnYnf3VTrQDtjva7tHATgJwyVpll/Zt5dGcCLVyWRaGqOeM xEfRv6ICJ77YJ/d488M9sImEzdzohkjqYeEokWrshBcJLowj8/AC7kYGXEyBQK+B i2Glx0P2DvZLnVCRpIwpfWevT1mCWnI1x3CKEiIKPmQOWd73OfdgeA7yVp+UpCCO nCSTQKYDINJ9KjFhFq39UtBOJsHJE4b1H1VZZtRmLlsAmghClW4yuxto3d2Q9/yZ HAG+ETfpv+JlLw7OR0bfOqSPWKIvJhaD+phAIwmHcUWP+RXqSYucfUMYvHFWlpkh MzXTUrGqJiuo5QQEa1UHIK+MODKipEJ8RJinyC+p+WurL7CxVNRFYObGR8lGXRj7 RPOPr6h7LMPk+fR92/7CAnG7rbfu9oKXAP5zJKwWblzypT/xTlq9mHjku1LKLVCh 7YHDD1qjlqFKdp9Ol1kLvX97VJZBUvi0Z27LT6LT+TWqmihZlw2qG6CeqBSDwcad tFKW93lWNxa6k72hJiKV/fRK2lMQMIX7iBXt7ABRChD2aAh8oTyqTWvjuvY8sDI+ zX1XGzao8fA= =PJaO -----END PGP SIGNATURE----- --Apple-Mail=_069E1DA9-DBAF-49DB-856C-1D9B01C42DAE-- --===============3849121833055630556== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ext3-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/ext3-users --===============3849121833055630556==--