19 Troubleshooting Storage Issues

19.1 Is DM-MPIO Available for the Boot Partition?
19.2 Btrfs Error: No space is left on device
19.3 Issues for Multipath I/O
19.4 Issues for Software RAIDs
19.5 Issues for iSCSI
19.6 Issues for iSCSI LIO Target

This section describes how to work around known issues for devices, software RAIDs, multipath I/O, and volumes.

19.1 Is DM-MPIO Available for the Boot Partition? #

Device Mapper Multipath I/O (DM-MPIO) is supported for the boot partition, beginning in SUSE Linux Enterprise Server 10 Support Pack 1. For information, see Section 7.12, “Configuring Multipath I/O for the Root Device”.

19.2 Btrfs Error: No space is left on device #

The root (/) partition using the Btrfs file system stops accepting data. You receive the error “No space left on device”.

See the following sections for information about possible causes and prevention of this issue.

19.2.1 Disk Space Consumed by Snapper Snapshots #

If Snapper is running for the Btrfs file system, the “No 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:

Log in as the root user, then open a terminal console.
Gain back enough space for the system to come up.
1. At the command prompt, enter
```
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
```
2. Enter
```
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 awhile (many hours for 1 TB) although the system is otherwise usable during this time.
List the snapshots in Snapper. Enter
```
snapper -c root list
```
Delete one or more snapshots from Snapper. Enter
```
snapper -c root delete #
```
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 defaults to be more aggressive in the /etc/snapper/configs/root configuration file, or for other mount points. Snapper provides three algorithms to clean up old snapshots. The algorithms are executed in a daily cron-job. The cleanup frequency is defined in the Snapper configuration for the mount point. Lower the TIMELINE_LIMIT parameters for daily, monthly, and yearly to reduce how long and the number of snapshots to be retained. For information, see Section “Creating and Modifying Snapper Configurations”, Chapter 4, System Recovery and Snapshot Management with Snapper, Administration Guide

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.

19.2.2 Disk Space Consumed by Log, Crash, and Cache Files #

If the system disk is filling up with data, you can try deleting files from /var/log, /var/crash, 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 the btrfs(8) manual page for more details.

19.3 Issues for Multipath I/O #

See Section 7.19, “Troubleshooting MPIO”.

19.4 Issues for Software RAIDs #

See Section 8.3, “Troubleshooting Software RAIDs”.

19.5 Issues for iSCSI #

See Section 14.5, “Troubleshooting iSCSI”.

19.6 Issues for iSCSI LIO Target #

See Section 15.8, “Troubleshooting iSCSI LIO Target Server”.

Print this page