Sparseness in storage
There are a lot of zeros out there. Efficient use of sparseness involves techniques to detect large quantities of zeros in advance rather than just reading them all. And on the write side there are standard techniques to append zeros to a file without actually writing them.
Seems a damn shame to read a terabyte of zeros and then write them to another device or file. Carrying the idea further: if we know random data has no meaning *** and we are asked to copy it, why not "write" zeros to the output file?
Over the last few years various commands have been added to the SCSI and ATA command sets to better handle sparseness (and trim/unmap/write_same can be viewed in this light). File systems are improving their sparseness handling as well, with Linux playing "catch up" to NTFS in this regard (e.g. the new FALLOC_FL_PUNCH_HOLE flag in fallocate() ).
So I am proposing a discussion of the:
- existing SCSI commands to support sparseness
- existing ATA commands to support sparseness
- suggestions for more sparseness support to be
added to the SCSI and ATA command sets
- user space tools that support sparseness
- file system support for sparseness
Perhaps the latter point should involve the file system track as well.
Doug Gilbert
20100202
*** For example: after ATA CRYPTO SCRAMBLE EXT command (which
is one of the "sanitize device" commands and is fast) the data read will be random and meaningless. If the disk does "read zero after trim" why not follow the scramble with a trim/unmap of the whole disk?
Quoted 3 lines · Douglas Gilbert
are improving their sparseness handling as well, with Linux playing "catch up" to NTFS in this regard (e.g. the new
FALLOC_FL_PUNCH_HOLEflag infallocate()).
FYI: XFS has supported hole punching for more than 15 years, although the first years obviously were't on Linux.
Quoted 7 lines · Christoph Hellwig
Quoted 3 lines · Douglas Gilbert
are improving their sparseness handling as well, with Linux playing "catch up" to NTFS in this regard (e.g. the new
FALLOC_FL_PUNCH_HOLEflag infallocate()).FYI: XFS has supported hole punching for more than 15 years, although the first years obviously were't on Linux.
I was looking at the Windows API yesterday and you need to check each volume for sparse support. So it is file system dependent there as well: VFAT doesn't support sparseness and NTFS (version ?) does.
From the perspective of user space tools, POSIX support for sparseness would be helpful and FALLOC_FL_PUNCH_HOLE looks like a step in that direction.
Doug Gilbert
Quoted 24 lines
-----Original Message-----
From: [email protected] [mailto:linux-scsi- [email protected]] On Behalf Of Douglas Gilbert
Sent: Wednesday, February 02, 2011 12:07 PM
To: linux-scsi
Subject: [LSF/MM TOPIC] Sparseness in storageThere are a lot of zeros out there. Efficient use of sparseness involves techniques to detect large quantities of zeros in advance rather than just reading them all. And on the write side there are standard techniques to append zeros to a file without actually writing them.
Seems a damn shame to read a terabyte of zeros and then write them to another device or file. Carrying the idea further: if we know random data has no meaning *** and we are asked to copy it, why not "write" zeros to the output file?
Over the last few years various commands have been added to the SCSI and ATA command sets to better handle sparseness (and trim/unmap/write_same can be viewed in this light). File systems are improving their sparseness handling as well, with Linux playing "catch up" to NTFS in this regard (e.g. the newFALLOC_FL_PUNCH_HOLEflag infallocate()).
Quoted 8 lines
So I am proposing a discussion of the:
- existing SCSI commands to support sparseness
- existing ATA commands to support sparseness
- suggestions for more sparseness support to be added to the SCSI and ATA command sets
- user space tools that support sparseness
- file system support for sparseness
On the last point I was talking to Ted on the same topic in Plumbers more so in the context of thin provisioned LUNs and he suggested creating profiles ...
The zeroes out there also tend to change I/O patterns which are quite tied to low-level chunk size details in storage SANs. I had like to think that the hole size could be linked to the chunk sizes exported by the Storage SANs and so it makes a lot of sense to create profiles.
Quoted 17 lines
Perhaps the latter point should involve the file system track as well.
Doug Gilbert
20100202*** For example: after ATA CRYPTO SCRAMBLE EXT command (which
is one of the "sanitize device" commands and is fast) the data read will be random and meaningless. If the disk does "read zero after trim" why not follow the scramble with a trim/unmap of the whole disk?
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 26 lines · Douglas Gilbert
There are a lot of zeros out there. Efficient use of sparseness involves techniques to detect large quantities of zeros in advance rather than just reading them all. And on the write side there are standard techniques to append zeros to a file without actually writing them.
Seems a damn shame to read a terabyte of zeros and then write them to another device or file. Carrying the idea further: if we know random data has no meaning *** and we are asked to copy it, why not "write" zeros to the output file?
Over the last few years various commands have been added to the SCSI and ATA command sets to better handle sparseness (and trim/unmap/write_same can be viewed in this light). File systems are improving their sparseness handling as well, with Linux playing "catch up" to NTFS in this regard (e.g. the new
FALLOC_FL_PUNCH_HOLEflag infallocate()).So I am proposing a discussion of the:
- existing SCSI commands to support sparseness
- existing ATA commands to support sparseness
- suggestions for more sparseness support to be
added to the SCSI and ATA command sets
- user space tools that support sparseness
- file system support for sparseness
Quoted 2 lines
Perhaps the latter point should involve the file system track as well.
Why not just acknowledge that arrays have some sort of allocation map and ask for a T10/SCSI command to return it.
Signature · 6 lines
Regards, Richard Sharpe -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html