From: 12345@whatismyemailaddress.xyz   
      
   	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?   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)