On Fri, 15 Feb 2013, thornber@xxxxxxxxxx wrote:
On Thu, Feb 14, 2013 at 06:07:56PM -0800, Eric Wheeler wrote: Discard support is the main user of the btree_remove, so turning off discard support in the pool should be a good temporary fix.
Yep, I did just that and it seems to be stable at the moment.
Could you let me know what sort of work load you were applying to the ext4 fs to cause this to happen? If I can reproduce this I should be able to get a fix to you v. quickly.
I'm sure it was very light load. Backups happen at night using rdiff-backup, but the failure was happening during the day outside of a backup period.
I do have a MySQL replication writing to a volume, so that would generate a few writes---but its an extremely-low-write database, so that seems unlikely.
The best I can think is something like mlocate was scanning the disk, so maybe just a filesystem traversal was doing it---but mlocate would have been read-only.
I wouldn't think so, but is it possible for a read to cause a discard under dm-thinp?
-Eric -- Eric Wheeler www.globallinuxsecurity.pro -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
