2009/9/7 Ritesh Raj Sarraf <r...@researchut.com>: > The Discard/Trim command is also available as part of the SCSI standard now. > > Now, if you look from a SAN perspective, you will need a little of both. > Filesystems will need to be able to deallocate blocks and then the same > should be triggered as a SCSI Trim to the Storage Controller. > For a virtualized environment, the filesystem should be able to punch holes > into virt image files. > > F_FREESP is only on XFS to my knowledge.
I found F_FREESP while looking through the OpenSolaris source, and it is supported on all filesystems which implement VOP_SPACE. (I was initially investigating what it would take to transform writes of zeroed blocks into block frees on ZFS. Although it would not appear to be too difficult, I'm not sure if it would be worth complicating the code paths.) > So how does ZFS tackle the above 2 problems ? At least for file backed filesystems, ZFS already does its part. It is the responsibility of the hypervisor to execute the mentioned fcntl(), wether it is triggered by a TRIM or whatever else. ZFS does not use TRIM itself, though it is not recommended to use it on top of files anyway, nor is there a need for virtualization purposes. It does appear that the ATA TRIM command should be used with great care though, or avoided all together. Not only does it need to wait for the entire queue to empty, it can cause a delay of ~100ms if you execute them without enough elapsed time. (See the thread linked from the article I mentioned.) As far as I can tell, Solaris is missing the equivalent of a DKIOCDISCARD ioctl(). Something like that should be implemented to allow recovery of space on zvols and iSCSI backing stores. (Though, the latter would require implementing the SCSI TRIM support as well, if I understand correctly.) Chris _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
