Configure ext3 Mounts Without Losing Journal Recovery

This guide configures an existing ext3 filesystem in /etc/fstab, makes its journalling choice explicit, and verifies the result after mounting. It takes about 15 minutes if the filesystem is already identified. You need a shell, the device or UUID, and root access for editing /etc/fstab and changing mounts. Do not use these steps to create a new filesystem: formatting the wrong device destroys data.

What the settings control

ext3 is ext2 with journalling. The journal protects filesystem metadata, so a crash can be recovered without treating every unclean shutdown as a damaged directory tree. It does not make unsynchronised application data durable, and it is not a backup.

The installed ext3(5) page is provided by e2fsprogs 1.47.0-2.4~exp1ubuntu4.1 here. The page is maintained with the ext4 documentation and describes three ext3 data modes:

• data=ordered is the default. Changed file data is written to the main filesystem before related metadata is committed to the journal.
• data=journal writes file data and metadata through the journal before writing the main filesystem. It gives the strongest crash-consistency behaviour of these modes, with extra writes.
• data=writeback journals metadata but does not preserve data ordering. After a crash, an old or otherwise stale block can appear in a recently changed file.

For a general-purpose ext3 volume, leave data=ordered in place or state it explicitly. Treat writeback as a deliberate workload decision, not a casual performance tweak.

1. Identify the filesystem before editing anything

Use ordinary privileges to list mounted ext3 filesystems and their current options. This is read-only:

findmnt --type ext3 --output TARGET,SOURCE,FSTYPE,OPTIONS
lsblk --fs

Expected output is a row such as:

TARGET SOURCE     FSTYPE OPTIONS
/srv/archive /dev/sdb1 ext3   rw,relatime,data=ordered

Your device and options will differ. If no ext3 row appears, stop and check the filesystem type shown by lsblk --fs. Do not infer ext3 from a directory name.

Record the stable UUID rather than relying on a device name that can change between boots:

findmnt --noheadings --output UUID --target /srv/archive

For an unmounted filesystem, replace the target with a device path:

blkid /dev/EXAMPLE_DEVICE

Both commands only inspect metadata. Replace /srv/archive and /dev/EXAMPLE_DEVICE with real values; the placeholders are not valid paths.

2. Choose the small set of options you actually need

The most useful ext3 options are the data mode and commit interval. commit=5 is the documented default: the journal is committed about every five seconds. A larger value can reduce commit activity but increases the amount of recent work at risk during sudden power loss. A value of 0 means the default, not "never commit".

Keep barrier protection enabled with barrier=1, the ext3 default. Barriers enforce on-disk ordering so volatile write caches do not reorder journal commits. Do not disable them merely because a benchmark is faster. If you have a specific storage design and a tested power-loss policy, barrier=0 is still a security and durability decision that belongs in its change record.

Do not add noload or its alias norecovery to a normal boot or service mount. Those options skip journal loading. If the filesystem was not cleanly unmounted, the skipped replay can leave inconsistencies and cause further problems. The kernel documentation also describes ro,noload as a way to prevent writes while examining a filesystem, but that is a specialist recovery procedure, not a routine mount policy.

3. Add a controlled fstab entry

Make a backup before changing the file. This is a privileged action because /etc/fstab controls future mounts and can affect boot:

sudo cp -p /etc/fstab /etc/fstab.before-ext3-change

Edit the file with the UUID you recorded:

sudoedit /etc/fstab

A representative entry is:

UUID=EXAMPLE-UUID /srv/archive ext3 defaults,data=ordered,commit=5,barrier=1 0 2

Keep the mount point and UUID specific to your host. The final 0 2 fields keep the usual non-root filesystem dump and boot-check ordering; confirm your distribution's policy if this is a production boot volume. If the filesystem is already mounted, changing fstab does not change the live mount until you remount or unmount and mount it again.

Checkpoint: validate the file before mounting

Run this as an ordinary user. It checks the filesystem table syntax and reports problems without mounting every entry:

findmnt --verify --verbose

Look for a successful verification rather than relying on an empty terminal. If it reports an unknown UUID, missing mount point or malformed option, fix that before continuing. A typo in fstab can prevent a boot-time mount, so keep the backup until the next reboot has succeeded.

4. Apply the options during a maintenance window

Mounting and remounting require elevated privileges and can disrupt services using the directory. Check who is using it first:

sudo fuser -vm /srv/archive

If the mount is not in use and you need to apply the complete entry, unmount and mount it again:

sudo umount /srv/archive
sudo mount /srv/archive

Do not force an unmount to make this work. Stop the owning service, or schedule the change. If unmounting fails, the filesystem is still in use; investigate the listed processes instead of adding more mount flags.

For a live filesystem that can tolerate a remount, use the narrow change you intend to make:

sudo mount -o remount,data=ordered,commit=5,barrier=1 /srv/archive

Remount support and restrictions depend on the running kernel and the existing mount. If the command fails, leave the current mount alone, use the unmount and mount procedure during maintenance, and check the kernel log for the reason.

5. Verify the live result and keep recovery available

Read the effective options after the change:

findmnt --target /srv/archive --output TARGET,SOURCE,FSTYPE,OPTIONS
findmnt --target /srv/archive --noheadings --output OPTIONS

The output should include ext3 as the type and the options you selected, although the kernel or mount helper may display equivalent normalised spelling. Confirm the mount source as well as the options so a similarly named directory does not fool you.

To inspect the filesystem's stored error policy without changing it, use the device path:

sudo tune2fs -l /dev/EXAMPLE_DEVICE | grep -E 'Filesystem features|Filesystem error behavior|Mount count|Last mount time'

The error policy is stored in the filesystem superblock and can be changed with tune2fs, but changing it is outside this mount configuration. The ext3 manpage lists errors=continue, errors=remount-ro and errors=panic; do not select a panic policy without understanding its effect on the whole machine.

If you need to undo this change, restore the saved file and reload only after checking it:

sudo cp -p /etc/fstab.before-ext3-change /etc/fstab
findmnt --verify --verbose
sudo mount /srv/archive

If a filesystem was not cleanly unmounted, do not use noload to hide the issue. Arrange downtime and run the appropriate filesystem check while it is unmounted, following your distribution's recovery procedure.