From: greymaus@dmaus.org   
      
   On 2022-12-04, John Smith <12345@whatismyemailaddress.xyz> wrote:   
   > 	I recently got a cheap 2T external USB SSD. I created a single   
   > Linux partition on it, which I formatted with the following command:   
   >   
   > 	mke2fs -F -L "SSD_2T" -t ext4 -O ^has_journal -O 64bit /dev/sdg1   
   >   
   > I had to use those two -O options to get rid of warnings that I was   
   > getting otherwise. This apparently works, in that I have been able to   
   > write to, and read from it without any issues: the data are there all   
   > right, and I can see no scary-looking diagnostics in /var/log/   
   > {syslog,messages} or from dmesg concerning this device.   
   >   
   > 	Since it was so cheap, I decided to get another one. With this   
   > second one, however, things are not so good: after invoking the same   
   > command as above, I get the following output:   
   >   
   > mke2fs 1.46.5 (30-Dec-2021)   
   > Creating filesystem with 511999745 4k blocks and 128000000 inodes   
   > Filesystem UUID: 8020357f-0732-4959-a71f-a3d687bbca7f   
   > Superblock backups stored on blocks:   
   > 	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632,   
   > 2654208,   
   > 	4096000, 7962624, 11239424, 20480000, 23887872, 71663616,   
   > 78675968,   
   > 	102400000, 214990848   
   >   
   > Allocating group tables: done   
   > Writing inode tables: done   
   > Writing superblocks and filesystem accounting information:   
   >   
   > Following the colon in the last line, the command starts printing out   
   > figures concerning the number of superblocks being written. However,   
   > after a few seconds there is no more output. The command is indeed still   
   > doing something, for I can see that the system activity goes up, and an   
   > LED in the device itself keeps blinking.   
   >   
   > 	The thing is, it does not seem to be making any progress - I left   
   > it running uninterruptedly for a whole day, to no avail. I tried again by   
   > removing the partition, recreating it, and creating the filesystem as   
   > above: no change. Every time the command is apparently unkillable for as   
   > long as the device is plugged in - it is only when I physically unplug it   
   > (thus eliciting a flurry of "Buffer I/O error on dev sdg1" diagnostics in   
   > dmesg) that the command stops.   
   >   
   > 	I initially concluded that the drive may be a lemon, but the fact   
   > is that it can be formatted as FAT32 without any problems. And as FAT32 I   
   > can use it without issues, but of course with the limitations of FAT32.   
   >   
   > 	Any ideas on why the ext4 filesystem creation may be getting   
   > stuck, and how to diagnose and hopefully fix it? Alternatively, what   
   > other filesystem could I try to use that is better than FAT32?   
      
      
   Please keep reporting on all this.   
   Thanks.   
      
      
   --   
   greymausg@mail.com   
      
   Fe, Fi, Fo, Fum, I smell the stench of an Influencer.   
   Where is our money gone, Dude?   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)