| |||||||||||||
Linux Storage and Filesystem Workshop, day 2Linux Storage and Filesystem Workshop, day 2Posted Apr 10, 2009 19:04 UTC (Fri) by giraffedata (subscriber, #1954)Parent article: Linux Storage and Filesystem Workshop, day 2
they will sell an array which claims to be much larger than the amount of storage actually installed. This is a really poor description of thin provisioning. For those who didn't get it: thin provisioning means the storage server allows you to create volumes whose total size exceeds the actual storage capacity of the system. So you don't buy disk drives to back the unused portion of those volumes.
But that leads to an interesting problem if trim is used to discard the contents of some blocks in the middle of the file. If the application later writes to those blocks - which are, theoretically, still in place - the system could discover that the device is out of space and fail the request. That, in turn, could lead to chaos. That's no more interesting than the simpler problem that when you go to extend a sequential file, the write request fails even though the filesystem has space available. These systems work only if you can manage the system in such a way that running out of actual storage space is about as rare as a power supply failure. That means keeping a large amount of unused space at all times and monitoring consumption rates. I think to do it right, the storage system would probably also have to slow down as it approaches full so as to protect itself from a runaway storage consumer.
(Log in to post comments)
Linux Storage and Filesystem Workshop, day 2 Posted Apr 17, 2009 21:10 UTC (Fri) by willy (subscriber, #9762) [Link] That's no more interesting than the simpler problem that when you go to extend a sequential file, the write request fails even though the filesystem has space available.This was in the context of an application having used the posix_fallocate() call. If that call succeeds, the application is guaranteed to be able to use the storage that has been so allocated. Thin Provisioning breaks this, and it's far from clear how to fix it.
Linux Storage and Filesystem Workshop, day 2 Posted Apr 18, 2009 22:10 UTC (Sat) by giraffedata (subscriber, #1954) [Link] That's no more interesting than the simpler problem that when you go to extend a sequential file, the write request fails even though the filesystem has space available.This was in the context of an application having used the posix_fallocate() call. If that call succeeds, the application is guaranteed to be able to use the storage that has been so allocated. Thin Provisioning breaks this, and it's far from clear how to fix it. No, posix_fallocate() doesn't guarantee you can use the storage. Your write to it could fail, for example, due to a media defect. What posix_fallocate() guarantees is that a write won't fail because there is no space left in the filesystem. That's the same guarantee you get from mkfs that if you create a 1G filesystem, you can put (about) 1G of files in it. So it's equally interesting that with thin provisioning, your fallocated space within a file may be unusable as that your filesystem space may be unusable for extending the file. With thin provisioning, the filesystem storage medium is a volume in the storage server, which does in fact have space for the write in question. What doesn't have space is the server's pool of backing storage, and the effect of that is a write to certain sectors of the volume fails.
Linux Storage and Filesystem Workshop, day 2 Posted Apr 20, 2009 14:35 UTC (Mon) by willy (subscriber, #9762) [Link] The text from the standard says:DESCRIPTIONI stand by my assertion that it is currently impossible to provide this with Thin Provisioning without actually writing to every single block.
Linux Storage and Filesystem Workshop, day 2 Posted Apr 20, 2009 16:05 UTC (Mon) by giraffedata (subscriber, #1954) [Link] That's entirely consistent with what I wrote. There is space in the filesystem. (If there weren't, the write would fail with ENOSPC and statfs() would show no space).The only problem is that writes to certain sectors of the storage medium fail for reasons out of the scope of POSIX. There's layering going on here.
|
|||||||||||||