Linked by moondevil on Wed 11th Jan 2012 00:10 UTC
Windows The latest blog entry from Steven Sinofsky about Windows 8 describes the Storage Spaces functionality . From the blog entry it seems Windows 8 is getting something ZFS-like. The Storage Spaces can be created in the command line via Powershell, or in the Control Panel for the ones that prefer a more mouse-friendly interface.
Thread beginning with comment 503011
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: OSNews RTFA and comments
by hechacker1 on Thu 12th Jan 2012 19:04 UTC in reply to "RE: OSNews RTFA and comments"
hechacker1
Member since:
2005-08-01

I don't understand this part. When you have virtual volumes made of several physical drives, isn't it possible to use, say, NTFS on every physical drive, and a much simpler virtual filesystem for the virtual drive that can be resized and remapped at will and transmits every "advanced" command (metadata, etc...) to the underlying physical FS ?


The difference you are talking about is only in implementation. You can either have an underlying NTFS partition with some type of file-system on top to combine it, or an underlying storage pool (like LVM), with a NTFS partition on top.

Does it really matter which way it's done? Not really.

What matters in this case is that when you do need to resize, it's a simple operation of adding another disk. There's no need to resize the filesystem, or rebuild the entire array to distribute parity. Each of those operations carries the risk of failure; while having over-provisioning from the start means that the storage pool has already considered those cases in its design.

7. It lets you specify a backing device for the journal (similar to Linux), so you could put the journal on a SSD for the storage pool, and really speed up the slowest parts of calculating parity and keeping a consistent state.

This leads me to ask something I've regularly wondered about on Linux : what happens if the journal is corrupted on a journalized FS ? SSDs often brutally fail without warning and with full loss of data, could the filesystem survive such an event if it was only its journal that was on a SSD ?


With ext4, if the journal is corrupted, then you can just discard it. You can fallback to ext4 mode without journaling (similar to ext2). The data itself will be fine, but anything in the journal could be lost. Then it's possible to rebuild the journal when you reactivate it on a new device.

NTFS has a similar structure. The journal can be disabled when required. With Windows 8, it can also be allocated to a faster device (finally!).

http://msdn.microsoft.com/en-us/library/windows/desktop/aa363877(v=...).aspx

Edited 2012-01-12 19:06 UTC

Reply Parent Score: 2

Alfman Member since:
2011-01-28

hechacker1,

"There's no need to resize the filesystem, or rebuild the entire array to distribute parity. Each of those operations carries the risk of failure; while having over-provisioning from the start means that the storage pool has already considered those cases in its design."

Your comments seem to imply that over-provisioning from the start is somehow more robust, but I cannot see why. I see the "thin provisioning" semantics and disk failure handling as two different variables. In other words, one doesn't require initial over-provisioning in order to achieve the fault tolerance you are describing, even during a resize.

We can agree it's better than what windows had before, but I'd still like you to justify why dynamic expansion with over-provisioning is superior to the same thing without over-provisioning? I get the feeling it's got to do with a quirk of their implementation rather than something that needed to be done that way.


"NTFS has a similar structure. The journal can be disabled when required. With Windows 8, it can also be allocated to a faster device (finally!)."

Just a nit pick, I don't think the journal needs to be on a "faster device". just having it on a separate device of the same speed would eliminate all the excess seeking on the primary device.

Reply Parent Score: 2

hechacker1 Member since:
2005-08-01

Without over-provisioning at the beginning, you are forced to run utilities (even in Linux) to:

1. Expand the volume onto a new disk.

2. Allow the underlying storage pool to recalculate and distribute parity for the new disk (which affects the entire pool).

3. Resize the file system on top with a tool. This can be fast, but it can also be slow and risky depending on the utility. NTFS generally can resize up well. Still, it's an operation were you probably want a backup before doing.

In contrast with over provisioning, you don't have to do the above steps. It's handled automatically and from the start.

With regards to having a SSD as a backing device, it allows you to speed up parity in situations like RAID 5. The read-modify-write cycle is slow to perform for a HDD, but fast for a SSD. Especially in cases where small writes dominate the workload. A SSD allows for fast random r/w, but then writes to the HDD pool can happen in a serialized operation.

Some RAIDs get around this problem with a volatile cache, but you are risking data to minimize the parity performance hit. Using an SSD means it's non-volatile and the journal could playback to finish the operation. I guess you could do it on a regular HDD, but you would still be measuring performance latency in 10s of milliseconds instead of <1ms. It's an order of magnitude difference.

It's all theoretical at this point, but Microsoft briefly mentioned having an SSD would be faster. We'll have to wait for more details.

Edited 2012-01-14 02:26 UTC

Reply Parent Score: 1