Re: [Discuss] Recovering a corrupted usb hard drive with XFS
> From: John Abreau > 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. >From the messages, I tend to agree with Gregory Galperin that you accidentally formatted sdx rather than sdx1, and then repeated using sdx rather than sdx1 when you mounted it. In particular, you saw this peculiar situation before *before* running xfs_repair: > /dev/sdf exists, but /dev/sdf1 does not. That indicates that at that point, the kernel couldn't see a partition table. And then fdisk reports that the disk starts with an XFS signature: > 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. Though that doesn't solve the problem. It seems like you need to verify the size of the filesystem, shrink it if necessary, then shift it later on the disk, then insert a GPT before the filesystem. In a perfect world, GParted could do this but I don't know if it can. I managed to find these with the query "use gparted to add a partition table to a disk that doesn't have one site:superuser.com": https://superuser.com/questions/1633123/how-to-partition-a-drive-that-has-no-partition-table-without-formatting https://superuser.com/questions/1200128/how-to-create-a-partition-table-on-a-drive-with-a-file-system-occupying-the-whol https://superuser.com/questions/1650509/add-gpt-to-disk-that-has-bare-ext4-file-system-without-data-loss In principal, it can be done by: (1) using the right utility to shrink the filesystem enough to leave space for the GPT, (2) copying the filesystem "further" into the disk by that amount (which mostly has to be done *in reverse* to not lose data, so it can't be done directly by dd), (3) creating the GPT, (4) inserting a partition entry that describes the existing filesystem. If you can back up the disk to somewhere, wiping the disk and rebuilding it is going to be easier and safer. Dale ___ Discuss mailing list Discuss@driftwood.blu.org https://driftwood.blu.org/mailman/listinfo/discuss
Re: [Discuss] disc...@lists.blu.org unsubscribed
Thank you. Much obliged. On Wed, 15 May 2024 15:55:20 -0400 Jerry Feldman wrote: > I have no idea you were unsubscribed. I just added you back. A while > back we had a conflict between https and http that has been causing > an issue with the mailman admin panel. > > On Wed, May 15, 2024, 3:48 PM Rich Pieri > wrote: > > > I appear to have been unsubscribed from the discuss list. I tried > > resubscribing from the web interface but it doesn't seem to be > > working. Did I miss something? > > > > Thanks. > > > > -- > > \m/ (--) \m/ > > -- \m/ (--) \m/ ___ Discuss mailing list Discuss@driftwood.blu.org https://driftwood.blu.org/mailman/listinfo/discuss
Re: [Discuss] Recovering a corrupted usb hard drive with XFS
Not sure why we're still beating this dead horse, but that's just not the case. When I formatted the drive, I formatted sdx1. It's not a matter of opinion, nor is it a subject for voting to decide what happened. The 18TB disk is the largest disk I own, and all my other disks were close to full when I purchased the 18TB disk. To back it up, I'd need to purchase yet another disk, and I don't plan on doing that for at least another year. More precisely, when the 18TB drive is getting close to full. On Wed, May 15, 2024 at 11:52 AM Dale R. Worley wrote: > > From: John Abreau > > > 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. > > From the messages, I tend to agree with Gregory Galperin that you > accidentally formatted sdx rather than sdx1, and then repeated using sdx > rather than sdx1 when you mounted it. In particular, you saw this > peculiar situation before *before* running xfs_repair: > > > /dev/sdf exists, but /dev/sdf1 does not. > > That indicates that at that point, the kernel couldn't see a partition > table. And then fdisk reports that the disk starts with an XFS > signature: > > > 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. > > Though that doesn't solve the problem. It seems like you need to verify > the size of the filesystem, shrink it if necessary, then shift it later > on the disk, then insert a GPT before the filesystem. In a perfect > world, GParted could do this but I don't know if it can. I managed to > find these with the query "use gparted to add a partition table to a > disk that doesn't have one site:superuser.com": > > > https://superuser.com/questions/1633123/how-to-partition-a-drive-that-has-no-partition-table-without-formatting > > https://superuser.com/questions/1200128/how-to-create-a-partition-table-on-a-drive-with-a-file-system-occupying-the-whol > > https://superuser.com/questions/1650509/add-gpt-to-disk-that-has-bare-ext4-file-system-without-data-loss > > In principal, it can be done by: (1) using the right utility to shrink > the filesystem enough to leave space for the GPT, (2) copying the > filesystem "further" into the disk by that amount (which mostly has to > be done *in reverse* to not lose data, so it can't be done directly by > dd), (3) creating the GPT, (4) inserting a partition entry that > describes the existing filesystem. > > If you can back up the disk to somewhere, wiping the disk and rebuilding > it is going to be easier and safer. > > Dale > ___ > Discuss mailing list > Discuss@driftwood.blu.org > https://driftwood.blu.org/mailman/listinfo/discuss > -- John Abreau / Executive Director, Boston Linux & Unix Email: abre...@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@driftwood.blu.org https://driftwood.blu.org/mailman/listinfo/discuss
Re: [Discuss] Recovering a corrupted usb hard drive with XFS
On 5/15/24 15:44, John Abreau wrote: my other disks were close to full when I purchased the 18TB disk. To back it up, I'd need to purchase yet another disk Indeed. I once heard as a metaphor* that a circus needs at least two elephants, because if one dies, it will require the second elephant haul away the first one. You have only one elephant. I'm so old that 18TB seems big to me. That's so much data that backing it up by ANY means is very non-trivial. Even if the disk could spit data at the maximum "super speed" of USB 3.0, isn't that still something like 10-hours just to fit so much data through the wire? -kb, the Kent who points out that circuses seem to be giving up on elephants. * It wasn't about disks when I first heard it, it was used to illustrate a truth of nuclear power plants. They also come in large increments. And are (almost?) always built in sets of two, or more. ___ Discuss mailing list Discuss@driftwood.blu.org https://driftwood.blu.org/mailman/listinfo/discuss
Re: [Discuss] Recovering a corrupted usb hard drive with XFS
One thing you can do is to set up a new partition table. Doing that does not erase. Formatting does overwrite data. But, I would practice with a thumb driver. On Wed, May 15, 2024 at 7:22 PM Kent Borg wrote: > On 5/15/24 15:44, John Abreau wrote: > > my other disks were close > > to full when I purchased the 18TB disk. To back it up, I'd need to > purchase > > yet another disk > > Indeed. > > I once heard as a metaphor* that a circus needs at least two elephants, > because if one dies, it will require the second elephant haul away the > first one. You have only one elephant. > > > I'm so old that 18TB seems big to me. That's so much data that backing > it up by ANY means is very non-trivial. Even if the disk could spit data > at the maximum "super speed" of USB 3.0, isn't that still something like > 10-hours just to fit so much data through the wire? > > > -kb, the Kent who points out that circuses seem to be giving up on > elephants. > > > * It wasn't about disks when I first heard it, it was used to illustrate > a truth of nuclear power plants. They also come in large increments. And > are (almost?) always built in sets of two, or more. > ___ > Discuss mailing list > Discuss@driftwood.blu.org > https://driftwood.blu.org/mailman/listinfo/discuss > -- Jerry Feldman Boston Linux and Unix http://www.blu.org/ ___ Discuss mailing list Discuss@driftwood.blu.org https://driftwood.blu.org/mailman/listinfo/discuss
Re: [Discuss] Recovering a corrupted usb hard drive with XFS
I'm coming into this rather late since I'd somehow been unsubscribed for the past month or so. Anywho... What does the command "blkid /dev/sdX" say? If the device is partitioned then it should return the partition type (PTTYPE): /dev/sda: PTUUID="2d5ed796-ad53-4317-a7bc-2e0ad85d90d1" PTTYPE="gpt" And if it is a filesystem directly on device then it will return the filesystem type (TYPE) instead along with some other information about the block device: dev/sda1: LABEL="SAMSUNG" UUID="3CA9-C777" BLOCK_SIZE="512" TYPE="exfat" PARTLABEL="Basic data partition" PARTUUID="dc7aaeeb-3124-4216-bfbd-ddecfe20d72b" If it's the latter then I strongly recommend finding some way to put a partition table on the drive, especially if the block size is 4K. I/O performance will suffer badly if the partition isn't properly aligned. -- \m/ (--) \m/ ___ Discuss mailing list Discuss@driftwood.blu.org https://driftwood.blu.org/mailman/listinfo/discuss
