I've got a new 2TB Toshiba external drive and I'm staring at a message which says

root@slacktop:~# mkfs.ext4 -m0 /dev/sdb1 | tee ~/refmt-xt2c.out
mke2fs 1.45.5 (07-Jan-2020)
Found a atari partition table in /dev/sdb1
Proceed anyway? (y,N)

This comes after following a tutorial which had me do

root@slacktop:~# parted /dev/sdb --script -- mklabel gpt
root@slacktop:~# parted /dev/sdb --script -- mkpart xt2cdata ext4 0% 100%

(I think I possibly went wrong in not using the tutorial's -F flag in

mkfs.ext4 -F /dev/sdb1

because that seemed unnecessary and unwise but maybe it's for exactly this and I should just hit 'y'?)

I used to know how to do this with fdisk but ever since this gpt crap, I've had nothing but trouble. I'm pretty sure I had this exact message before and somehow got past it but I don't remember what I did. I did come across someone else with the same issue

http://gparted-forum.surf4.info/viewtopic.php?id=17729

but the idea of resizing the partition a couple of times doesn't seem quite right to me - I'd like to just say Y and have it Just Work or say N and be able to fix it some other way, but I'm not sure what'll happen after I say either.

On a newish laptop with a non-current Slackware-current... and when oh when is Slack 15 ever going to "BE READY"? Anyway - using parted-3.3-x86_64-1 and e2fsprogs-1.45.5-x86_64-1. Any tips will be greatly appreciated.

When it took over an hour for the above post to be moderated and appear, I gave up and hit 'y'. Seems to have worked except that now, when I mount the drive, the light won't quit blinking - it's only supposed to do that when there's disk activity. GKrellM is showing a constant oscillation between 2.1 and 4.2 megs of read activity. That can't be good. If anyone knows what's specifically causing this (the formatting glitch?, a mechanically faulty drive?, etc.) or how to fix it, I'd also appreciate that.

It's pretty neat, libblkid and parted both have crazy detection of all kinds of systems you wouldn't think were relevant today. E.g. I've seen parted think it's looking at nilfs or pc98. What it's looking at are generally superblock magic numbers (with the superblock for said system being at a different offset than for ext4, somewhere you might have written data that just happened to come our that way) or else, if I can remember rightly, the pc98 case has to do with plausible pc98 boot sector stuff in the 2nd sector. They had a variation on mbr that was a bit more advanced, taking 1024 bytes instead of only 512. Wish the rest of us could have had it up til GPT came along.

How about restarting at the partitioning stage after trying to wipe off what might be the troublesome sectors? If you have sgdisk around, sgdisk -Z wipes out both mbr sectors and GPT sectors. Then repeat your parted commands and mke2fs. If you still have the problem, well, if you don't have anything on the disk dd if=/dev/zero of=/dev/sdb should wipe anything confusing out of there (I mean it will wipe the whole disk). As usual with dd type the command, stand up, look out the window, look at the command again, double check it against mounted devices you see with df, etc. etc., play a bit of chess to focus the mind, look again etc. etc That is unless you have a cat. Best to be a bit more quick about it in case he notices the dd command and gets to the keyboard before you. Cats are well versed in these kinds of commands.

2 members found this post helpful.

+1 for the cat

Thanks for the reply! I used sgdisk and repeated the process and it did work without any complaints, but I think also just insisting 'y' did that because I still have the insane "writing* multi-megs constantly to the disk without using any additional space" problem. (In other words, the "atari" confusion isn't causing the problem I still have.) The drive properly blinks briefly when I plug it in. It then stops properly. It properly blinks briefly when I mount it and then properly stops... for a second, before it goes into its constant blink-and-write routine. I unmount it and it stops blinking. After awhile, it blinks briefly again to say its going to sleep, does so, and the light turns off. Everything seems fine except, y'know, when I try to use it. I mean, even that works in a way - it writes properly when I touch a file or create a directory and it removes them properly.

Any ideas on that part?

* I said "read" earlier, but it seems to indicate it's writing.

So it's an external drive eh? How's it connected to the machine? I'd want to run smartctl -t short and smartctl -t long, then after a few hours to let the long test run, run smartctl -a /dev/sdb. But smartctl won't work over usb cables I think. It would have to be connected via sata.

How do you see that multimegs get written to the disk? Are you running iostat or seeing it in another utility? I'd try to find what process is writing there. fuser looks to have a handy option, the --mount option. It will tell you the process ids of whatever has a file open on /dev/sdb1 if you run fuser -v --mount /dev/sdb1. lsof might be handy too.

Yep, it's a 2TB Toshiba external USB drive. I'm seeing the disk writes by gkrellm displaying on my fvwm desktop. And thanks again - now I'm getting somewhere (I hope). It just seemed like some bizarre magic write so it didn't even occur to me to use lsof to look for an actual process causing it, but it turns out its the kernel process jbd2. At least, that's the only process that shows via fuser or lsof and when I mount the drive read-only (which I think prevents journal updates under normal circumstances), the light stays steady and the disk writes don't happen. It's even finally gone to sleep while mounted.

So now I guess the question is "What's screwed up about the journaling process and how do I fix that?" I've had the "wrong partition" problem before, but I've never had this one.

Additional datapoints: I reformatted with reiserfs and everything seems fine. However, when I tried ext3, it took hours and I gave up and went back to reiserfs. I used to use reiser all the time over ext3 but certain events made it seem wise to move away from it. Anyone know its current/future status? Likely to stay supported for awhile, etc? If there's no major reason not to, I think I'll just leave it like this. Unless this all indicates a hardware issue and reiser's just making it work temporarily or something.

I wonder if there aren't bad sectors. smartctl can't work over usb but badblocks can. If it's not an SSD that might reveal something.

You're over the atari problem but here's something for future reference. At work (wasn't talking about your issue, just happenstance) a guy introduced me to the wipefs tool from util-linux. It's pretty neat. You can run it with -n (or no flags?) and it will tell you all the filesystem magic numbers it finds (whether they ought to be there or are ghosts of file systems past). E.g. here are some of my partitions:

That ext2 magic number showing up on sda7 is pretty weird. I'm counting myself lucky I don't get headaches from that. From now on I'll have to make it a habit to blow away any data on a partition before mkfs (or at least running wipefs to "hide" magic numbers).

On the journalling issue, I did encounter something like that once at work but can't remember what it was. Sticking with reiser sounds good to me. Despite the rumors of ext2 problems in 5.13, it doesn't strike me as being characteristic of Linux to drop support for anything. But if you do try ext3 or ext4 again there are ways to diagnose corrupt journals I think. Start with dumpe2fs I suppose.