Obviously, it should be 'Flash, a ha, Saviour of the Universe' but there's enough going around about flash at the moment. There's also a lot going around on various blogs about Thin Provisioning and especially space reclamation i.e how you get space back from file-systems after files have been deleted etc. It seems that the approach is to make the file-system aware of the storage and get them to communicate allowing deleted blocks to be reclaimed.
All fine and funky but to do this, the file-systems are going to need to be changed; at the moment, Veritas are on-board but we really need Microsoft on-board, perhaps engage the guys who are working on BTRFS for Linux and perhaps Sun for ZFS. If the industry does not get these guys onboard, this will be another good idea which peters out unfortunately. Oh yes, almost forgot; you've got to get VMWare onboard as well because I could see some really bad interactions with things like linked-clones in the future.
Whatever happens needs to be standards based at some point; it must be robust, must not impact non-thinly provisioned storage. Why standards based? I do have cases where a server sees storage from different vendors; I don't want to have treat file-systems differently depending on which storage array it is provisioned from. It'll just add another maintenance headache to my life.
There are various proposals being discussed in the T10 SCSI standards committee. So I expect a SCSI standard to be forthcoming.
NTFS (Windows has other issues) like its re-use of free space today. i.e. it writes to the end of the disk before trying to garbage collect – nice ?!
This was another excellent post. Thanks.
Sometimes I think the design of file-systems is too important to be left to the likes of Microsoft 😉
This blog entry I wrote this week may be of interest; http://blogs.netapp.com/shadeofblue/2008/10/really-thin-pro.html and http://blogs.netapp.com/shadeofblue/2008/10/hole-punching-f.html. There’s a link there to NetApp’s T10 proposal http://www.t10.org/ftp/t10/document.08/08-070r0.pdf
Not a big fan of thin provisioning, mostly because the while the storage may be aware of the filesystem (and that’s debatable) you can’t yet make the filesystem aware of the storage.
I have a customer. (so many good stories start like this) This particular nightmare of a customer is one that would take thin provisioning and run with it. The down-side is that they tend to run at 80-90% of capacity across the board. Nothing like having to add disks to a storage pool 20 minutes from full.
The downside to Thin Provisioning of block-level storage is that when the disk fills up, corruption can occur because as far as the file allocation table goes there is plenty of room.
It’s also a good way to bring an entire datacenter to a halt because someone isn’t paying attention.
Alex, indeed aware of your blog entries on the subject. Not keen on the SnapDrive approach simply because it is another piece of software to be installed and is another piece of software to be maintained. If you saw the list of things which are already included in our standard builds, you’d understand why.
And Jesse, I think the problem is that your customer needs to manage and be aware of what is going on in their environment a bit more. Also, as I mentioned in an earlier blog entry, just because you’ve allocated a large LUN, you don’t need to stick a file-system on all of it.
Thin-provision a LUN and when the file-system starts to fill, increase the size of the file-system. This encourages good management as the first the user sees is the file-system filling up and it is amazing what can be deleted once they see that. Once they have house-kept and then discover they need more storage, simply increase the size of the file-system.
Most modern filesystems can cope with being grown on the fly and an increasing number can cope with being shrunk on the fly as well.
But by TPing the LUN initially, all of this work can be done by the server admins and does not have to involve the storage guys; or if they are the same people, it reduces the amount of work they have to do.