I'm experiencing a 100% reproduceable misbehaviour of
fstrim, which seems to put data integrity on stake:
Whenever I use "fstrim" on a just newly "mkfs.xfs"ed
filesystem on a newly installed SSD (Crucial_CT1024M550SSD1,
firmware MU01), I get (after some activity on the device)
this error message:
> fitrim ioctl failed: input/output error
Looking into the dmesg output reveals:
> [1039455.530947] sd 0:0:1:0: [sdb]
> [1039455.533192] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
> [1039455.535369] sd 0:0:1:0: [sdb]
> [1039455.537521] Sense Key : Illegal Request [current]
> [1039455.539684] Info fld=0x772cdab0
> [1039455.541802] sd 0:0:1:0: [sdb]
> [1039455.543877] Add. Sense: Logical block address out of range
> [1039455.545966] sd 0:0:1:0: [sdb] CDB:
> [1039455.548008] Unmap/Read sub-channel: 42 00 00 00 00 00 00 00 18 00
> [1039455.550080] end_request: critical target error, dev sdb, sector 1999428272
(I bought 4 of the same SSD model, and the error occurs the same with
the other exemplars, so I can assume this is not some hardware issue.)
The "Logical block address out of range" error says no less than that
fstrim issued a fitrim ioctl that was asking the device to discard the
content of sectors well beyond the boundaries of the device. If it
wasn't for the "end of the physical device" making the SSD return an error,
if instead there was another partition behind a filesystem to trim, then
valuable, live data would have been discarded.
I've tried the same with ext4 instead of XFS, and the very same
error occurs, just with a slightly different sector being named
by the dmesg error output:
> [710565.947608] end_request: critical target error, dev sdb, sector 2000158720
Here's a list of properties of the system that might be
relevant for the issue:
According to smartctl, the capacity of this SSD is:
> User Capacity: 1,024,209,543,168 bytes [1.02 TB]
> Sector Sizes: 512 bytes logical, 4096 bytes physical
And cat /proc/partitions tells:
> major minor #blocks name
> 8 16 1000204632 sdb
Kernel is mainline linux-3.17.1
fstrim --version says:
> fstrim from util-linux 2.23.2
Distribution is CentOS 7.
mkfs.xfs -V says:
> mkfs.xfs version 3.2.0-alpha2
rpm -qif /usr/sbin/mkfs.xfs
Name : xfsprogs
Version : 3.2.0
Release : 0.10.alpha2.el7
(Should I be concerned that CentOS 7 comes with a mkfs.xfs
version having an -alpha2 suffix?)
The filesystem is created with:
mkfs.xfs -l lazy-count=1 -f /dev/sdb
meta-data=/dev/sdb isize=256 agcount=4, agsize=62512790 blks
= sectsz=4096 attr=2, projid32bit=1
= crc=0
data = bsize=4096 blocks=250051158, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=0
log =internal log bsize=4096 blocks=122095, version=2
= sectsz=4096 sunit=1 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
The filesystem is mounted with:
mount /dev/sdb /mnt/PFexp1
fstrim was started this way:
> fstrim -v /mnt/PFexp1
fstrim: /mnt/PFexp1: FITRIM ioctl failed: Input/output error
The relevant strace output of the above fstrim command:
stat("/mnt/PFexp1", {st_mode=S_IFDIR|0755, st_size=6, ...}) = 0
open("/mnt/PFexp1", O_RDONLY) = 3
ioctl(3, FITRIM, 0x7fff0733a4c0) = -1 EIO (Input/output error)
Any idea why that happenes?
Do we need to fear a loss of data when using fstrim in general?
Regards,
Lutz Vieweg
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
