[Discuss] Recovering a corrupted usb hard drive with XFS

John Abreau abreauj at gmail.com
Thu May 9 14:22:24 EDT 2024 

On Thu, May 9, 2024 at 12:27 PM Gregory Galperin <grg at csail.mit.edu> wrote:

> ...
> if you run [g]parted and it still shows no partitions, are you sure you
> ever had a partition on this drive, rather than having created the
> filesystem on the whole drive in the first place?  e.g. do you have fstab
> entries from this disks's normal system setup that shows it's mounted under
> a partition number?
>

The drive was never in fstab; my usb drives are automounted under
/run/media/jabr/ .

Yes, I'm sure it had a partition table; when I first set up each of my usb
drives, I reformatted the pre-existing NTFS partition with an XFS
filesystem.


> other indicators: does the filesys start at the very beginning of the
> drive, or is it offset (leaving space for a partition table (gpt))?
>

I just ran od -c on the recovered drive, and again on three of the other
drives for comparison. The other three show the text "EFI PART" at 0001000
and "XFSB" at 4000000, whereas the recovered drive shows "XFSB" at 0000000,
Looks like xfs_repair, when run on /dev/sdf instead of /dev/sdf1, rebuilt
the filesystem over the partition space.

So it's too late now to rebuild the partition table. I guess I'll just have
to live with it as-is.


> it makes me a little suspicious that the tools recognize a valid xfs
> filesystem on /dev/sdf -- I'm wondering if that means the filesys
> is starting right at the beginning of the disk, no space for a gpt, so
> it never had any partitions.
>

Nothing suspicious about it. By running xfs_repair on the raw disk, it
scanned the raw disk to find the xfs metadata with no regard for
partitioning.

The other three drives show "Disklabel type: gpt", "Units: sectors of 1 *
512 = 512 bytes", and a single partition beginning at 2048.

With a block size of 512 bytes, 2048 blocks == 1048576 bytes, and 1048576
in decimal == 4000000 in octal. So that checks.

I imagine the drive must have originally shipped with the first partition
beginning at 2048, and the earlier EFI stuff was part of some
Windows-related cruft from the factory image the drives are initially
seeded with.

On Thu, May 09, 2024 at 11:11:03AM -0400, John Abreau wrote:
> > I just checked with "journalctl -xe" after another unsuccessful attempt
> to
> > mount the drive, and found a duplicate UUID error.
> >
> > A quick google search of the error message yielded the solution: I ran
> > "sudo xfs_admin -U generate /dev/sdf"
> > and was then able to mount /dev/sdf successfully.
> >
> > I'm not thrilled about mounting sdf instead of sdf1. Is there any way to
> > safely reconstruct the partition table based on the info returned by
> > xfs_info?
> >
> > On Wed, May 8, 2024 at 8:40 PM John Abreau <abreauj at gmail.com> wrote:
> >
> > > I have an 18TB external hard drive that recently suffered a loss. When
> I
> > > first set it up, I formatted it as a single partition with an xfs
> > > filesystem.
> > >
> > > Yesterday I was trying to figure out how to export it via nfs, and
> during
> > > one of my attempts I used "mount --bind" to mount it under /export.
> > >
> > > Later, when I was backing out my tests, I found I was unable to unmount
> > > the drive because it was apparently still in use by a bash process
> that no
> > > longer existed. I clicked the "unmount anyway" button, and afterward
> > > discovered that the partition was missing from the drive. /dev/sdf
> exists,
> > > but /dev/sdf1 does not.
> > >
> > > When I ran fdisk to examine the drive, it gave the following error:
> > >
> > > Welcome to fdisk (util-linux 2.39.4).
> > >> Changes will remain in memory only, until you decide to write them.
> > >> Be careful before using the write command.
> > >
> > >
> > >
> > >> The device contains 'xfs' signature and it will be removed by a write
> > >> command. See fdisk(8) man page and --wipe option for more details.
> > >
> > >
> > >
> > >> Device does not contain a recognized partition table.
> > >> The size of this disk is 16.4 TiB (18000174383104 bytes). DOS
> partition
> > >> table format cannot be used on drives for volumes larger than
> 2199023255040
> > >> bytes for 512-byte sectors. Use GUID partition table format (GPT).
> > >
> > >
> > > Created a new DOS (MBR) disklabel with disk identifier 0xb9e277e5.
> > >
> > >
> > > I immediately exited fdisk without writing it out.
> > >
> > > I tried running "xfs_repair -L /dev/sdf", which appears to
> > > have successfully repaired the xfs filesystem, but the partition table
> > > still has no partitions showing, and the disk still won't mount.
> > >
> > > "xfs_info /dev/sdf" shows the following:
> > >
> > > meta-data=/dev/sdf               isize=512    agcount=17,
> agsize=268435455
> > > blks
> > >          =                       sectsz=4096  attr=2, projid32bit=1
> > >          =                       crc=1        finobt=1, sparse=1,
> rmapbt=0
> > >          =                       reflink=1    bigtime=0 inobtcount=0
> > > nrext64=0
> > > data     =                       bsize=4096   blocks=4394573824,
> imaxpct=5
> > >          =                       sunit=0      swidth=0 blks
> > > naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
> > > log      =internal log           bsize=4096   blocks=521728, version=2
> > >          =                       sectsz=4096  sunit=1 blks,
> lazy-count=1
> > > realtime =none                   extsz=4096   blocks=0, rtextents=0
> > >
> > > As far as I can tell, the filesystem itself is in good shape, and I
> just
> > > need to fix the partition table. But I don't know how to do that
> without
> > > risk of destroying the filesystem. I've had no luck googling a useful
> > > answer.
> > >
> > > How do I fix this?
> > >
> > >
> > >
> > > --
> > > John Abreau / Executive Director, Boston Linux & Unix
> > > Email: abreauj at gmail.com / WWW http://www.abreau.net / PGP-Key-ID
> > > 0x920063C6
> > > PGP-Key-Fingerprint A5AD 6BE1 FEFE 8E4F 5C23  C2D0 E885 E17C 9200 63C6
> > >
> > >
> >
> > --
> > John Abreau / Executive Director, Boston Linux & Unix
> > Email: abreauj at gmail.com / WWW http://www.abreau.net / PGP-Key-ID
> 0x920063C6
> > PGP-Key-Fingerprint A5AD 6BE1 FEFE 8E4F 5C23  C2D0 E885 E17C 9200 63C6
> > _______________________________________________
> > Discuss mailing list
> > Discuss at driftwood.blu.org
> > https://driftwood.blu.org/mailman/listinfo/discuss
>


-- 
John Abreau / Executive Director, Boston Linux & Unix
Email: abreauj at gmail.com / WWW http://www.abreau.net / PGP-Key-ID 0x920063C6
PGP-Key-Fingerprint A5AD 6BE1 FEFE 8E4F 5C23  C2D0 E885 E17C 9200 63C6

More information about the Discuss mailing list