Formatting an external USB SSD device

[John Smith]

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?

[John Forkosh]

...Since it was so cheap, I decided to get another one.
With this second one, however, things are not so good...

Just guessing -- did you remember to fdisk this second drive
before mke2fs'ing it? (And, btw, exactly what ssds are these?)

[greymaus]

Post by John Smith
I recently got a cheap 2T external USB SSD. I created a single
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
mke2fs 1.46.5 (30-Dec-2021)
Creating filesystem with 511999745 4k blocks and 128000000 inodes
Filesystem UUID: 8020357f-0732-4959-a71f-a3d687bbca7f
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
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.

[Henrik Carlqvist]

Post by John Smith
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?

Putting a file system on a partition does not mean writing to every byte
of that partition and writing different file systems might write to
different bytes. If you have some unwritable bytes on the drive, even if
you are able to put a file system on it you might get trouble later.

If you wan't ext4, you might be able to run badblocks on the partition
during creation of the file system, it will make the creation slower, but
if you suspect a bad drive I would use the option "-c" twice to mke2fs to
do a slow read-write test on the entire drive.

As you have disabled the journal on the file system you might just as
well consider the ext2 file system.

When mke2fs seems hung and unkillable you can still look for clues about
what is going on.

Maybe the output from the command "dmesg" can give some clue.

ls -al /proc/`pidof mke2fs`/fd

might show which file descriptor is pointing to the partition and if that
is say number 7 you can study the contents of:

cat /proc/`pidof mke2fs`/fdinfo/7

...to see if something happens to the file position.

Another tool to see if something is going on is strace:

strace -f -p `pidof mke2fs`

regards Henrik

[Aragorn]

Post by Henrik Carlqvist
As you have disabled the journal on the file system you might just as
well consider the ext2 file system.

That's not really correct. ext4 is a lot more than ext2 with
journaling added. You're probably thinking of ext3, which is indeed
basically ext2 with journaling, albeit that even ext3 supports hashed
trees — they're disabled by default but they can be enabled — which
ext2 did not support yet.

ext4 uses hashed trees and extents, rather than blocks, and it caches
more aggressively. So even with journaling disabled, it'll still be
quite a bit faster than ext2 or ext3.

ext4 also has performance optimizations for SSDs — e.g. it'll use a
different I/O scheduler by default when the "ssd" mount option is
specified — which its predecessors didn't have yet.

That said, considering that they are (removable) SSDs, the OP may even
consider other options than ext2/3/4, such as F2FS, YAFFS2, et al.
F2FS for instance has already long been a mature filesystem and was
specifically designed for flash-based storage.

[Ralph Spitzner]

Post by John Smith
I recently got a cheap 2T external USB SSD. I created a single

the last 2TB external HDD! I bought on ebay was a usb stick and some
weights ....
a 2TB _internal SSD comes at anything between 100 and 200 EUR,
How much did you pay ?
Also try dd(rescue) to try and write /dev/zero to them and see where it
stops....


-R