Red Hat Bugzilla – Bug 467181
[RFE] GFS2: Add support for storage discard requests
Last modified: 2009-10-01 05:28:19 EDT
To support media which understands such things, thin provisioning, etc., we need to add support to GFS2 for generating storage discard requests for blocks which are no longer in use when they have been deallocated from the filesystem. Since the API has now hit upstream, this bug is a reminder to add the feature at some future point.
Created attachment 331116 [details] Initial patch First go at this. Generates -EOPNOTSUPP nicely :-)
Testing notes: Many thanks to dwmw2 for the follwoing suggestion (modified slightly by me to make a device large enough for gfs2): modprobe mtdram total_size=1048576 modprobe mtdchar ftl_format /dev/mtd0 modprobe ftl (you'll need mtd-utils installed to do the above) mkfs.gfs2 -p lock_nolock /dev/ftla mount -t gfs2 /dev/tfla /mnt/foo It is then possible to read the discard requests using blktrace. You will need to use blktrace from rawhide though, because older versions do not support the discard requests. You should then see something like this, when discards are generated (i.e. at the log flush after an unlink): 44,0 0 22 0.003422720 20363 Q DB 266576 + 255 [sync] 44,0 0 23 0.003424206 20363 G DB 266576 + 255 [sync] 44,0 0 24 0.003425825 20363 P N [sync] 44,0 0 25 0.003426254 20363 I D 266576 + 255 [sync] 44,0 0 26 0.003431552 20363 Q DB 266831 + 255 [sync] 44,0 0 27 0.003433048 20363 G DB 266831 + 255 [sync] 44,0 1 10 0.003434462 11012 D D 266576 + 255 [ftld] 44,0 0 28 0.003435730 20363 I D 266831 + 255 [sync] 44,0 0 29 0.003438522 20363 Q DB 267086 + 255 [sync] 44,0 1 11 0.003438747 11012 C D 266576 + 255 [0] 44,0 1 12 0.003441752 11012 D D 266831 + 255 [ftld] 44,0 0 30 0.003443356 20363 G DB 267086 + 255 [sync] 44,0 0 31 0.003444156 20363 I D 267086 + 255 [sync] 44,0 0 32 0.003446110 20363 Q DB 267341 + 43 [sync] 44,0 1 13 0.003446336 11012 C D 266831 + 255 [0] D = discard DB = discard, barrier otherwise, its the usual blktrace/blkparse output format.
I seem to have found a gfs_controld bug too while testing this. It seems that gfs_controld almost always dies with the following message when I do the mount in the sequence above (comment #3), the only time I can get it to work is when I'm tracing it with gdb which seems to fix the issue. The kernel is the latest upstream -nmw kernel. gfs_controld[2374]: segfault at 1 ip 000000353ce80e20 sp 00007fff3b882018 error 4 in libc-2.9.so[353ce00000+168000] cman version details: [root@men-an-tol steve]# rpm -qi cman Name : cman Relocations: (not relocatable) Version : 2.99.12 Vendor: Fedora Project Release : 1.fc10 Build Date: Mon 03 Nov 2008 03:23:24 PM GMT Install Date: Fri 05 Dec 2008 02:55:31 PM GMT Build Host: x86-1.fedora.phx.redhat.com Group : System Environment/Base Source RPM: cluster-2.99.12-1.fc10.src.rpm Size : 2768548 License: GPLv2+ and LGPLv2+ Signature : DSA/SHA1, Tue 04 Nov 2008 06:32:23 PM GMT, Key ID bf226fcc4ebfc273 Packager : Fedora Project URL : http://sources.redhat.com/cluster/wiki/ Summary : Red Hat Cluster Manager Description : Red Hat Cluster Manager
Also, I forgot the -o discard option on the mount command line in comment #3, but that makes no difference to the bug of comment #4.
The discard patch is now in the -nmw git tree, since I've been able to do some testing with it.
It looks like this is a nolock filesystem... gfs_controld shouldn't be involved in anything, it doesn't even need to be running. A random guess would be that your changes to the kernel/user uevent interface are doing something new/different/unexpected.
In 2.6.30