This is a $199 (early 2023)/$150 (late 2023) 4TB USBA (3.2) <-->USBC (Android) external SSD drive. We're capped at about 800MB of data transfer, but being external obviates annoying NVMe (PCI only) issues. With SSD's, only writing, not reading, decreases their lifespan. I'm thinking of these in terms of 10 year lifespans.
$ lsusb
Bus 003 Device 009: ID 0634:5602 Micron Technology, Inc. CT4000X6SSD9
$ lsblk
sdc 8:32 0 3.6T 0 disk
├─sdc1 8:33 0 128M 0 part
└─sdc2 8:34 0 3.6T 0 part /run/media/foo/Crucial X6
$ cat /etc/mtab
/dev/sdc2 /run/media/foo/Crucial\040X6 exfat rw,nosuid,nodev,relatime,uid=0500,gid=0500,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro 0 0
FS considerations
The X6 comes with an extended FAT (exfat) 3.6TB partion and thus syncs to MSoft devices with an added file management area "System Volume Information" of about 128Mb. Should we keep the exfat? Extended FAT has an upper recommended partion limit of 512Tb, so the drive is well-within it's useful partition size, and it's also compatible with Apple devices. YMMV but, in my systems, I prefer zero MSoft either in applications, file systems, or anything else.
A person might next consider formatting to ext2. I've found it reliable for more than a decade. However 2038 is the final time-stamp date available for ext2 files -- ext2 was released in 1993 -- so ext2 is unfortunately nearing some expiration considerations.
Luckily, any FS we want will do fine: external drives don't need to boot, and we only need a single partition to store data. BtrFS supposedly has flexible inode size (so can manage smaller and larger files side by side), but Oracle was involved in its development. Currently, I believe xfs is worth a try, in absence of ext2. Xfs is the default on RedHat systems so it has active development. As for ext4, this Reddit post compares ext4 and xfs. We may also want to soon consider zfs, since it's gaining momentum with large stakeholders.
XFS
Pretty sure xfs will not natively mount in a Windows or iOS systems and has the option of encryption, but it also has a drawback: appropriates journaling space. RedHat has info, of course, and the Arch guide is also good. XFS.org also has its own FAQ.
# umount /dev/sdc
# gparted /dev/sdc [eliminate present stuff, add xfs partition]
# mkfs.xfs -L "bigdrive" /dev/sdc1
# xfs_repair /dev/sdc1
# chown 0500:0100 /run/media/foo/bigdrive
The reason for the xfs_repair is to verify it formatted successfully.
The reason for the chown: for some reason, gvfs mounts xfs as root:root (0:0) instead of the standard user:group setup. Since gvfs mounts other USB drives to group 100, I chown-ed the drive to UID:group, that is to 0500:0100. Can also chown to 0500:0500 if desired, that is user:user (supposing, eg one's UID were 500).
I only had to chown it once and gvfs subsequently auto-mounted the drive with the correct permissions.
If stripe and strip parameter warnings appear, read this and ignore them. That's for RAIDs.
No comments:
Post a Comment