This section describes some known issues and possible solutions for file systems.
The root (/) partition using the Btrfs file system
stops accepting data. You receive the error
No space left
See the following sections for information about possible causes and prevention of this issue.
If Snapper is running for the Btrfs file system, the
space left on device problem is typically caused by
having too much data stored as snapshots on your system.
You can remove some snapshots from Snapper, however, the snapshots are not deleted immediately and might not free up as much space as you need.
To delete files from Snapper:
Open a terminal console.
At the command prompt, enter btrfs filesystem show, for example:
tux > sudo btrfs filesystem show Label: none uuid: 40123456-cb2c-4678-8b3d-d014d1c78c78 Total devices 1 FS bytes used 20.00GB devid 1 size 20.00GB used 20.00GB path /dev/sda3
sudo btrfs fi balance start MOUNTPOINT -dusage=5
This command attempts to relocate data in empty or near-empty data chunks, allowing the space to be reclaimed and reassigned to metadata. This can take a while (many hours for 1 TB) although the system is otherwise usable during this time.
List the snapshots in Snapper. Enter
sudo snapper -c root list
Delete one or more snapshots from Snapper. Enter
sudo snapper -c root delete SNAPSHOT_NUMBER(S)
Ensure that you delete the oldest snapshots first. The older a snapshot is, the more disk space it occupies.
To help prevent this problem, you can change the Snapper cleanup
Cleanup-algorithms, (↑Administration Guide) for
details. The configuration values controlling snapshot cleanup are
EMPTY_*, NUMBER_*, and
If you use Snapper with Btrfs on the file system disk, it is advisable to reserve twice the amount of disk space than the standard storage proposal. The YaST Partitioner automatically proposes twice the standard disk space in the Btrfs storage proposal for the root file system.
If the system disk is filling up with data, you can try deleting files from /var/log, /var/crash, /var/lib/systemd/coredump and /var/cache.
The Btrfs root file system subvolumes /var/log, /var/crash and /var/cache can use all of the available disk space during normal operation, and cause a system malfunction. To help avoid this situation, SUSE Linux Enterprise Server offers Btrfs quota support for subvolumes. See Section 1.2.5, Btrfs Quota Support for Subvolumes for details.
On test and development machines, especially if you have frequent crashes of applications, you may also want to have a look at /var/lib/systemd/coredump where the coredumps are stored.
On solid-state drives (SSDs) and thinly provisioned volumes it is useful to trim blocks not in use by the file system. SUSE Linux Enterprise Server fully supports unmap or trim operations on all file systems supporting these methods.
The recommended way to trim a supported file system (except Btrfs) on SUSE Linux Enterprise Server is to run /sbin/wiper.sh. Make sure to read /usr/share/doc/packages/hdparm/README.wiper before running this script. For most desktop and server systems the sufficient trimming frequency is once a week. Mounting a file system with -o discard comes with a performance penalty and may negatively affect the lifetime of SSDs and is not recommended.
WARNING: Do Not Use wiper.sh on Btrfs
The wiper.sh script trims read-write mounted ext4 or XFS file systems and read-only mounted/unmounted ext2, ext3, ext4, or XFS file systems. Do not use wiper.sh on the Btrfs file system as it may damage your data. Instead, use /usr/share/btrfsmaintenance/btrfs-trim.sh which is part of the btrfsmaintenance package.