/dev/blog

Labelling a partition can be quite handy, especially for partitions on usb drives that usually get auto-mounted to a folder that corresponds to their label.

Usually the label is set when the partition is created. If the label is not explicitly specified, it is usually auto-generated. To change the label, there are a couple of tools available:

ext2/ext3/ext4 partitions

You can either use e2label

# e2label device [newlabel]

or tune2fs

# tune2fs -L [newlabel] device

FAT/FAT16/FAT32 partitions

Again, there are multiple tools available, from simple perl scripts to mtools, but the easiest to use is probably dosfslabel from the dosfstools package

# yum install dosfstools
[...]
# dosfslabel device [newlabel]

NTFS partitions

ntfslabel is available as part of the ntfsprogs package

# yum install ntfsprogs
[...]
# ntfslabel device [newlabel]

Mounting an ext3 partition using ext4 fs drivers will usually speed-up your filesystem without actually changing the on-disk structures. Therefore it’s possible to revert to the ext3 driver without any problem. This allows you to easily benefit from delayed allocation (delalloc) and multi-block allocation (mballoc).

Further performance enhancements are possible if you do change the on-disk structure, e.g. by using extents. The downside is that you can’t mount the filesystem any longer with kernel lacking ext4 support and you can’t revert.

To enable ext4 features on an existing ext3 filesystem, invoke:

tune2fs -O extents,uninit_bg,dir_index /dev/DEV 

Unfotunately, features like flex_bg and >16TB fs support can only be enabled at format time¹.

Your filesystem is now indeed converted to ext4, however, only files that are written after conversion will benefit from ext4 extends. Existing files would have to be rewritten. e4defrag is being developed to take care of this but in now meant for production environments as of now.

A workaround would be to use chattr to rewrite the files using extends. From the archlinux wiki:

find /home -xdev -type f -print0 | xargs -0 chattr +e
find /home -xdev -type d -print0 | xargs -0 chattr +e

It is being recommended though, “to test this command on a small number of files first, and check if everything is going all right. It may also be useful to check the filesystem after conversion.“². Please note their warnings about mercurial repositories and hardlinks in general, too.

[1] https://wiki.archlinux.org/index.php/Ext4#Migrating_files_to_extents
[2] https://ext4.wiki.kernel.org/index.php/Ext4_Howto#Converting_an_ext3_filesystem_to_ext4

By default, 5% of a new ext2/3/4 partition will be reserved for important root processes and for fs performance reasons. However, there may be sound reasons to lower that percentage or even disable it completely (non-root partition, data-only storage, huge files, ext4 etc.).

Let me quote Linux filesystem guru Ted Ts’o on this:

If you set the reserved block count to zero, it won’t affect performance much except if you run for long periods of time (with lots of file creates and deletes) while the filesystem is almost full (i.e., say above 95%), at which point you’ll be subject to fragmentation problems. Ext4′s multi-block allocator is much more fragmentation resistant, because it tries much harder to find contiguous blocks, so even if you don’t enable the other ext4 features, you’ll see better results simply mounting an ext3 filesystem using ext4 before the filesystem gets completely full.

If you are just using the filesystem for long-term archive, where files aren’t changing very often (i.e., a huge mp3 or video store), it obviously won’t matter.

You can change the reserved block percentage by invoking

tune2fs -m 1 /dev/sdb1

or disable it completely:

tune2fs -m 0 /dev/sdb1

To check, how many block are reserved on a given filesystem, run

tune2fs -l /dev/sdb1 | grep "Reserved block count"

Of course, you have to adjust /dev/sdb1 to your needs.

Resources:
http://unix.stackexchange.com/questions/7950/reserved-space-for-root-on-a-filesystem-why
See also tune2fs manpage