Linux - Storage : hard drives, USB keys, ...


How to find which filesystem any specific file belongs to ?

df path/to/file

Example :

Filesystem		1K-blocks	Used		Available	Use%	Mounted on
/dev/mapper/vg-home	25066604	4513268		19256952	19%	/home


How to mount filesystems automatically at boot ?

There are several options to automatically mount a filesystem at boot time :

How to optimize SSD usage ?

  1. The only SSD drives I'm using so far are in Debian machines, so I will only list commands and tools related to this operating system. Nevertheless, overall concepts may apply to other environments.
  2. "Optimizing" means finding the best mix of :
    • read / write performance
    • drive lifetime
    • configuration / tweaking time
  3. The Internetz suggests lots of things / hacks. Some are true, some are not, and most of them may just be obsolete.
Statement : "You MUST ..." Status Comment
... buy a SLC SSD drive it depends
  • SLC, MLC and TLC SSD drives all have their pro's and con's. From the fastest / highest number of writes / most expensive to the slowest / lowest writes / cheapest (sources : 1, 2) :
    1. SLC
    2. MLC
    3. TLC
  • buy one that fits both your needs and your budget
... leave space for over-provisioning true
  • this is considered a safe practice, the only dispute being the amount of unallocated space : 7% of the drive capacity, with a maximum of 10GB. Newer drives have some built-in unallocated space for this, which isn't accessible to the user, so no need to leave unused space. (source)
  • this is not completely clear to me whether "over-provisioning" is :
    • having some free space on the drive (within partitioned space)
    • OR leaving some partitioned space
... align partitions to 32 bits / 4K false
  • the requirement to align partitions was obsolete even before SSDs existed. This only comes from a limitation in the BIOS itself, and has nothing to do with SSD drives or GNU/Linux (source)
  • since Wheezy, tools handle this automatically
... have SWAP and tmpfs filesystems NOT on the SSD true
  • this will save writes on the SSD and make it last longer
  • Debian already puts tmpfs filesystems in memory (details)
... use ext4 true
  • ext4 works just fine with SSDs (sources : 1, 2)
... use the noatime mount option true
... use the discard mount option false
... use the data=ordered mount option false
... setup a regular TRIM with cron false
  • TRIM is not necessary : in some situations, TRIM can improve speed —in other cases, it can make the system significantly slower. And it is only ever a help until the disk is getting fairly full.
  • What do you lose if you DON'T enable TRIM ?
    When a filesystem deletes a file, it knows the logical blocks are free, but the SSD keeps them around. When the filesystem re-uses them for new data, the SSD then knows that the old physical blocks can be garbage-collected and re-used. So all you are really doing by not using TRIM is delaying the collection of unneeded blocks. As long as the SSD has plenty of spare blocks (remember over-provisioning ?), TRIM gains you nothing at all here.
... worry about wear leveling TODO
... use SSDs in RAID for extreme performance TODO I've read somewhere this is a bad idea, offering no performance improvement

Can't mount NTFS-formatted USB drive : Error mounting /dev/sde1 at /mount/point: Unknown error when mounting /dev/sde1


/dev/sde1 : When I plug it on the Debian machine, I get this message on an pop-up window of the graphical interface :
Error mounting /dev/sde1 at /mount/point: Unknown error when mounting /dev/sde1


fdisk -l /dev/sde1
This command and further interactive checks with fdisk list data normally :
  • device name and manufacturer
  • partition label, size
  • ability to read partition table, toggle flags, write changes, undo them, ...
showing there seem to be no hardware damage to this device .
mount /dev/sde1 /mount/point
ntfs_mst_post_read_fixup_warn: magic: 0x5acebe02  size: 4096   usa_ofs: 30771  usa_count: 3182: Invalid argument
Actual VCN (0x57f9577b3dca807b) of index buffer is different from expected VCN (0x0).
Failed to open $Secure: No such file or directory
Failed to mount '/dev/sde1': No such file or directory
ntfsfix -n /dev/sde
Mounting volume... NTFS signature is missing.
Attempting to correct errors... NTFS signature is missing.
Failed to startup volume: Invalid argument
NTFS signature is missing.
Trying the alternate boot sector
The alternate bootsector is usable
Set sector count to 60437491 instead of 60435443
The startup data can be fixed, but no change was requested
Volume is corrupt. You should run chkdsk.
No change made			ok since this was a dry-run
ntfsfix -d /dev/sde
Mounting volume... NTFS signature is missing.
Attempting to correct errors... NTFS signature is missing.
Failed to startup volume: Invalid argument
NTFS signature is missing.
Trying the alternate boot sector
The alternate bootsector is usable
Set sector count to 60437491 instead of 60435443
Rewriting the bootsector
The boot sector has been rewritten
ntfs_mst_post_read_fixup_warn: magic: 0x00000000  size: 1024   usa_ofs: 0  usa_count: 0: Invalid argument
Record 0 has no FILE magic (0x0)
Failed to load $MFT: Input/output error
Volume is corrupt. You should run chkdsk.			will do, thx 
chkdsk (on the W10 box) was helpless)
chkdsk on the Windows machine :
Sadly, chkdsk provided no useful help since it was only able to complain:
Windows cannot access the F: drive.
  • At least, it didn't suggest to contact my administrator .
  • The good news is that the flash drive was "alive" enough to get a drive letter (which it didn't get before using ntfsfix.)
/sbin/badblocks -vs /dev/sde
Checking blocks 0 to 30218745
Checking for bad blocks (read-only test): done
Pass completed, 0 bad blocks found. (0/0/0 errors)
This took about 20 minutes for a 32GB drive.


Looks like this is "only" a software error, even though I have no idea about the root cause. I've not been able to fix it (and save the data ), and the solution was to :
  1. delete + re-create the partition, with fdisk in interactive mode
  2. format it :
    mkfs.ntfs -f -L myUsbFlashDrive /dev/sde1
    • -f : fast format : skip both zeroing of the volume and bad sector checking
    • -L volumeLabel : set the volume label to volumeLabel
  3. And voilà !

Filesystem in USErspace aka FUSE

FUSE is a simple interface for userspace programs to export a virtual filesystem to the Linux kernel. It also aims to provide a secure method for non privileged users to create and mount their own filesystem implementations.


error : fuse: bad mount point `/mount/point': Transport endpoint is not connected (source) :

Just unmount and re-mount :
fusermount -uz '/mount/point' && mount '/mount/point'

Comparison of filesystems

Common / current filesystems :

FS features + -
  • fragments data
    • fragmentation is less an issue with SSDs
    • use the autodefrag mount option or defragment on a regular basis
    • defragmentation does not preserve extent sharing (e.g. files created by cp --reflink or existing on multiple snapshots). Due to that the data space consumption may increase.
  • df and du may report approximate/misleading values (source), consider btrfs fi usage
  • RAID5 and RAID6 are considered unstable on BtrFS (details)
  • De-duplication will lead to increased fragmentation.
  • supported by all distros
  • based on ext3, meaning it's widely tested, stable and proven
  • focused on performance and scalability
  • good for desktop and server use
  • unclean shutdown-resistant
  • low fragmentation (e4defrag)
  • best of both worlds between ext4 and XFS
  • fast, reliable, can stand load without eating CPU
  • less prone to fragmentation than ext3
  • lower performance than ext4
  • _may_ lose data because of postponing journal writes
  • FS + volume manager
  • protection against data corruption : integrity checking for both data and metadata with checksums
  • transparent compression
  • hardware-accelerated native encryption
  • snapshots
  • Copy-On-Write
  • data de-duplication
  • OpenZFS vs XFS
  • data de-duplication requires lots of RAM (source)
  • best for extremely large file systems, large files, and lots of files
  • great on parallel I/O
  • highly configurable
  • lower performance on single threaded, metadata-intensive workloads (such as creating/deleting numerous small files) (source)
  • file fragmentation due to COW. xfs_fsr path/to/file defragments the specified file / the most fragmented files
  • does not handle unclean shutdowns very well : potential data loss on power cut (UPS recommended!)
  • overkill for desktop use
  • De-duplication will lead to increased fragmentation.
The table above is a best-effort summary of my readings. There is a lot to say about filesystems (features, limitations, ...), and when looking for the "best" of them, the only possible answer is It depends on what you value most :
  • reliability
  • performance
  • scalability
  • administration cost : time, effort, complexity
  • built-in features : journaling, compression, encryption, copy-on-write, snapshots, online resizing, rotational disks / SSD optimizations, ...
Anyway, this research also highlighted that :
  • ext4 is still a pretty decent general-purpose solution, both for desktops and servers
  • other filesystems will prove useful in special situations where some specific features are expected and some time is dedicated to tuning and administration

Last minute thoughts

criteria for choosing a filesystem :
  • amount of data to store
  • type of data to store :
    • mostly small / medium / large / huge files ?
    • compressible data ? This excludes JPEG / MP3 / video / files
    • are your applications filesystem-agnostic ? Do they tend to handle tasks usually devoted to the FS ?
  • which specific features are you considering using ?
  • which level of performance do you expect under YOUR workload ? In other words : under low workloads, you may not notice a difference .
typical conversation about filesystems on the Internetz :
  • Bob : I like filesystem X because of feature. I've been using it on some kind of hardware, it's VERY reliable.
  • Kevin : I lost a whole disk because of filesystem X, so now I prefer filesystem Y.
  • Stuart : Got data corruption on filesystem Y. Using filesystem Z and it "just works" so far.
  • No filesystem is "perfect enough" so that nobody ever had a problem with it.
  • You can never be sure which of filesystem X or anything else actually caused the data loss : hardware also fails sometimes and PEBKAC mustn't be forgotten .
  • The Internetz are full of people complaining, people don't post when things work fine.
  • The Internetz never forget, blog posts and comments grow old too. Maybe the issue you're reading about has been fixed years ago.
  • Don't make decisions based on the opinion of random users : get facts.

Other filesystems

Here are some filesystems I list for completeness, but these are old / obsolete / not worth considering anymore as of 2023.
FS + -
ext2, ext3 obsolete, use ext4
ReiserFS Performs great with numerous files + small files
  • Reiser3 is now obsolete
  • Reiser4 is still being maintained, but unlikely to be merged into mainline Linux without corporate backing
  • ZFS was published in 2005 by Sun Microsystems, as part of the OpenSolaris OS, under an open source licence
  • ZFS has been ported to FreeBSD (shipped in 2008 in version 7.0), Linux and even Apple
  • then in 2010 Oracle bought Sun Microsystems, and ZFS became proprietary software, known as Oracle ZFS
  • so developers forked the last public release of OpenSolaris and created the OpenZFS project
  • OpenZFS is still administered with commands like : zfs [command]
  • when saying ZFS in the Linux / FreeBSD world, people actually mean OpenZFS
  • no idea how features compare between OpenZFS and Oracle ZFS

How to use a NTFS drive ?

  1. apt-get install ntfs-3g
  2. plug the drive, identify + mount it
  3. append to /etc/fstab :
    UUID=1A0B4F9B2D10391B	/mount/point	ntfs-3g	noauto,users,uid=1000,gid=1000,dmask=022,fmask=133	0	0

So far, only root can mount a NTFS filesystem. However, thanks to the uid=1000,gid=1000 parameters, the corresponding non-root user has write access to the volume.


Permission denied when trying to write to the filesystem

We're not supposed to lose access rights overnight, let's have a look at some conditions leading to this error.

hypothesis : McAfee software

This is definitely not the most common cause of Permission denied errors for Linux users, but when crap like McAfee Endpoint Security for Linux Threat Prevention (ENSLTP) service is around, better checking this first because I've seen it be responsible for most errors.
  • try to stop / restart the service and check whether you still get Permission denied
  • check the corresponding process is still alive

hypothesis : file write access is blocked by SELinux

There is a lot more to say about SELinux (which I did here). Having it early in this list is not to call it the perfect culprit for Permission denied errors, but since this is a rather complex topic I'm far from being an expert on, better checking ASAP the points I may have failed to configure properly. The basic test below is just to check whether or not SELinux is causing the Permission denied.
Get the current SELinux mode :
  • Permissive : in this mode, SELinux does not block file access, hence can not be the cause of the Permission denied error
  • Enforcing : SELinux is currently enforcing rules and possibly blocking file access
    1. set SELinux into Permissive mode :
      setenforce 0
    2. try again to write the blocked file :
      • allowed : SELinux is the culprit, you'll have to investigate + fix rules
      • still denied : SELinux is not the one preventing file write
    3. set SELinux back to Enforcing mode :
      setenforce 1

hypothesis : wrong / insufficient Unix permissions

f: /path/to/some/specific/file
drwxr-xr-x root     root     /
drwxr-xr-x root     root     path
drwxr-xr-x kevin admins to
drwx------ kevin admins some
drwx------ kevin admins specific
-rw-rw-r-- kevin admins file

hypothesis : the filesystem is full

  • as a non-root user, I should have received a No space left on device error
  • root has some reserved space on filesystems to be able to debug / fix them when they're full
so this is not very likely.
Filesystem              Size  Used Avail Use% Mounted on
/dev/mapper/crypt-root  936G  251G  638G  29% /

hypothesis : the filesystem is out of inodes

df -i / the filesystem /path/to/some/specific/file belongs to was returned by the df -h above
Filesystem               Inodes  IUsed    IFree IUse% Mounted on
/dev/mapper/crypt-root 62373888 627135 61746753    2% /

hypothesis : the filesystem is mounted read-only

findmnt | awk '$1 =="/"'
/				/dev/mapper/crypt-root ext4		rw,relatime,errors=remount-ro

hypothesis : immutable directory in the path

  1. cd to the highest directory you have write access to (/ for root, something lower for others)
  2. create a test file :
    touch testFile && rm testFile
  3. if this works, go down one level on /path/to/some/specific/file and try again creating a test file until you get a Permission denied error
  4. at that time, the parent of the current directory _may_ have been made read-only via its immutable attribute
    1. check it :
      lsattr parentDirectory
      ----i-------- parentDirectory
    2. if this was not made on purpose, it can be reset with:
      chattr -i parentDirectory

hypothesis : ACL

From the previous step, you may have found a directory in which you can't write, whereas you still have write access to its parent. Check ACL :
getfacl directoryInWhichYouCanNotWrite

hypothesis : other security/policy-enforcing software

Start by checking whether any of theses tools is currently installed :

hypothesis : anything else

At that point, you'd be entitled to feel being in the Twilight Zone or considering voodoo to get this sorted out, because this is getting seriously weird. Some last points worth checking :
  1. have a look at logs, just in case something went wrong at boot time :
    • dmesg
    • less /var/log/messages
  2. consider fscking the filesystem
  3. I'm out of ideas

How to mount an ext4 disk on a system which kernel only knows ext4 as a development filesystem ?

To do so, you'll have to ask the kernel to consider this filesystem as a test filesystem.

tune2fs -E test_fs /dev/sdb1 && mount -t ext4dev /dev/sdb1 /mnt/tmp

Details :

  1. specify advanced disk parameters : tune2fs -E test_fs /dev/sdb1.
    • -E is for tune2fs extended options.
    • test_fs is a flag instructing the kernel to use experimental code (such as ext4dev) to mount the disk.
  2. "debug" the filesystem to view/edit its state ( ??? not always necessary) and open it in r/w mode : debugfs -w /dev/sdb1
  3. check filesystem flags : tune2fs -l /dev/sdb1 | grep flags should output Filesystem flags: signed_directory_hash test_filesystem
  4. then mount : mount -t ext4dev /dev/sdb1 /mnt/tmp

Don't forget that on recent distributions, the ext4 filesystem is not available in "dev" anymore as it is now fully supported by the kernel.


How to rename a USB mass-storage device (=change its label ) ?


When I plug a USB mass-storage device (USB key, external HDD, CF card, ...), it appears with a pre-defined name in Nautilus. How can I change this ?


Actually, the name used in Nautilus to refer to a USB mass-storage device is matched to this device mounting point : if the device is mounted in /media/device_xyz, the device will be displayed as device_xyz in Nautilus.

Fine then, but where does this device_xyz come from ? As most of the time USB storage devices are formatted with FAT filesystems (FAT 16 / FAT 32), their name is just the DOS partition label. To change this, 2 solutions :


Smoothly change the partition label with mtools (as root on FAT volumes) :
  1. ignore warnings :
    echo mtools_skip_check=1 >> ~/.mtoolsrc
  2. read the label :
    mlabel -i /dev/sdg1 -s ::
  3. change the label :
    mlabel -i /dev/sdg1 ::newLabel

Alternate solution

The quick-n-dirty method is to format the partition while giving it a new name :
mkfs.vfat -n newName /dev/sdf1

Which filesystem from a USB device should I mount ?


I've plugged my USB key / external HDD, automount is OFF and I don't know which filesystem to mount


Which /dev/sdxx matches my USB device ?



How to change a volume label ?

For EXT volumes (source 1, 2) :

e2label /dev/sdc1 newLabel

For FAT volumes :

How to rename a USB mass-storage device (=change its label ) ?

What are inodes ?

Definitions (source) :

  • an inode (aka index node)
    • is a data structure in a Unix-style file system
    • describes a filesystem object :
      • file
      • directory
    • stores (full list)
      • location of disk blocks of the object's data
      • the object's attributes
      • but does NOT store the file name itself, which is done by its parent directory
  • a directory is a list of inodes with their assigned names (i.e. an ID ↔ name list). The list includes an entry for
    • itself
    • its parent
    • each of its children
  • the inode number of a file is its unique id in the FAT
  • in most Linux filesystems —including ext3 and ext4— the inode number is a 32-bit unsigned integer (i.e. an integer such as : 0 ≤ n ≤ (232 - 1), source)

Get a file's inode :

  • number :
    ls -i fileName
  • full data :
    stat fileName

Monitor inode usage :

df -hi

Every filesystem can handle a limited number of inodes (the inodes table uses space, so allowing a huge number of files on a filesystem means a big inode table, hence less space for files.). When running out of free inodes, there are 3 solutions :

  1. remove old / unused files
  2. move files to another filesystem
  3. dump the filesystem and re-create it with a larger inodes table

Delete a file from its inode number :

find path/to/be/searched -inum inodeNumberOfFileToDelete -delete


How to always mount a specific USB storage device at a specific mount point ?

For any personal reason, I'd like my USB key to always be mounted into /media/usbKey/ and my USB HDD into /media/usbHdd/. Indeed, depending on the DOS-label of the media (if any), and on the plugging order, I have no control on the mount point, which can be critical if I want to build scripts accessing content on removable media.

The UUID method :

  1. as root :
    /dev/sdd1: LABEL="ConPow" UUID="05b3250f-3478-4831-8a85-c8da270839c3" TYPE="ext3"
  2. For the ConPow volume, add into /etc/fstab :
    UUID=05b3250f-3478-4831-8a85-c8da270839c3	/media/ConPow	ext3	noauto,users	0	0
  3. Don't forget to create the mount point and to manage permissions accordingly

Let non-root users mount + have write access to filesystems :

As root :
  1. specify either the user or users option in /etc/fstab
  2. manually mount the filesystem
  3. "give" the mount point to the user :
    chown bob:users /mount/point/
  4. unmount the filesystem
You should be able to mount this filesystem and write there as bob, now

The udev method :

This method is more complex and takes longer to apply than the UUID method above. It _may_ also be obsolete. It's still there only for "historical" reasons.
  1. Identify the device :
    • fdisk -l
    • or less /proc/partitions
    • or mount | grep "sd"
    • or cat /etc/mtab | grep "sd"
    which may output : /dev/sdf1 on /media/usbdisk type ext3 (rw,nosuid,nodev)
  2. Investigate the device :
    udevadm info --name=/dev/sdb1 --attribute-walk
    looking at device '/devices/pci0000:00/0000:00:13.2/usb2/2-2/2-2:1.0/host12/target12:0:0/12:0:0:0/block/sdb/sdb1':
    looking at parent device '/devices/pci0000:00/0000:00:13.2/usb2/2-2/2-2:1.0/host12/target12:0:0/12:0:0:0/block/sdb':
    looking at parent device '/devices/pci0000:00/0000:00:13.2/usb2/2-2/2-2:1.0/host12/target12:0:0/12:0:0:0':
  3. Write the udev rule into /etc/udev/rules.d/10-local.rules :

    KERNEL=="sd?1", ATTRS{size}=="1250263728", ATTRS{capability}=="50", KERNEL=="sd?1", NAME="ConPow"

    More about udevinfo, udev rules syntax and basic udev rules
  4. Restart udev : service udev restart
  5. Create the mount point /media/ConPow
  6. Finally, to give it a fixed mount point, append to /etc/fstab :

    /dev/ConPow /media/ConPow ext3 auto,user 0 0

  7. Don't forget to unplug/replug the USB drive (or to /etc/init.d/udev restart)so that it gets re-discovered and handled by the udev rule.
  8. At this step, "normal" users still have not enough privileges to write on the device : set permissions

Additional stuff:

Instead of the UUID, it is possible to identify filesystems by their volume label. This volume label can be specified while creating the file system :

On existing filesystems, this can be done with tune2fs. Then, it is possible to mount filesystems, or refer to them in /etc/fstab with the label keyword.


A FAT32-formatted USB key suddenly complains bus error and is remounted read-only.


  1. I plug my USB key and mount it normally
  2. I use it as usual for a while
  3. Suddenly, when trying to read from it, it says bus error.

What's going on ?


  1. mount outputs /dev/sdd1 on /media/myUsbKey type vfat (ro, ... ,errors=remount-ro)
    So it seems some error occurred on the device and -as instructed- it's been remounted read-only.
  2. dmesg is more verbose :
    [ 5962.398581] FAT-fs (sdd1): error, fat_get_cluster: invalid cluster chain (i_pos 14085575)
    [ 5985.072996] FAT-fs (sdd1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
    [ 5995.422661] FAT-fs (sdd1): error, fat_get_cluster: invalid cluster chain (i_pos 14085575)
    [ 5995.422671] FAT-fs (sdd1): Filesystem has been set read-only

For a detailed view on how things work, read this ServerFault discussion (or a local copy)


  1. Try to fix the filesystem automatically : fsck.msdos -aw /dev/sdd1
  2. If this doesn't work, try a manual approach : fsck.vfat /dev/sdd1
    If it highlights differences on the "boot sector" :
    There are differences between boot sector and its backup.
    Differences: (offset:original/backup)
    1) Copy original to backup
    2) Copy backup to original
    3) No action
    think twice before overwriting usable data with 0's (have another look at the article I linked above !)
  3. As for me, this didn't work either, so I had to backup everything then format the USB drive and it works fine anew

How to clone a CD ?

  1. Insert the source CD into the reader, but do not mount it.
  2. Copy the source CD to the hard disk as a bitstream: dd if=/dev/hdx of=/path/to/image.iso
  3. Identify the SCSI fake number ID of the CD writer :
    cdrecord -scanbus
    It should output an ID such as : x,x,x
  4. To blank a CD-RW :
    cdrecord blank=fast dev=x,x,x
  5. Then burn :
    cdrecord -v speed=[2/4/6/8/10/12/...] dev=x,x,x /path/to/image.iso
  6. The CD writer unit is /dev/scdx

How to connect a USB Digital Camera (and play with SCSI emulation) ?

With modern distributions, all steps below are now handled automatically / differently and this whole procedure is now obsolete. I keep it for "historical" reasons.

  1. Ensure all the required kernel modules are loaded (usb-storage is mandatory, others are usually already loaded) : lsmod | grep 'usb'
  2. If usb-storage is not currently loaded : modprobe usb-storage
  3. Check that USB drivers (especially usb-storage) are ready : less /proc/bus/usb/drivers
  4. Connect the USB device, turn it on, then list all currently connected USB devices : less /proc/bus/usb/devices | grep "S:"
  5. Since USB devices are emulated through SCSI, list all found SCSI devices : less /proc/scsi/scsi
  6. Read complete information about the SCSI-emulated USB device : less /proc/scsi/usb-storage-0/x (x is the id of the SCSI device, starting at 0)
  7. Create a mount point : mkdir /mnt/usb
  8. SCSI devices are named sxxi, with :
    • xx : 2 letters identifying the type of device:
      • cd : CD, DVD, CD-Recorder unit
      • d[a-g] : storage device. The 1st one is da, then db, etc. The letter corresponds to the device order within all the devices of the same family (for example, the 1st HDD drive is sda even if there are other SCSI devices)
    • i : device or partition number. Keep in mind that FAT32 partitions usually start numbering at 5.
  9. mount the device : mount /dev/sda1 /mnt/usb