Urgent: Recommended sector size for use with 64 KB NTFS

[Axel Mertes]

Hi Romex Software Support,

I am about to reformat a large RAID 6 storage array, which I am going to use with a L2 SSD cache using PrimoCache Server.

I have formatted the L2 cache SSD using 64 KByte NTFS blocks.
So I will do the same with the RAID 6 storage array: Formatting it with 64 KByte NTFS size.

However, I can set a custom sector/cluster size within the RAID 6 controller, ranging from 512 Bytes up to 4 KByte.

My urgent and important question here:

Which sector/cluster size would you recommend me to use in this scenario?

Thanks in advance for a quick reply,

Axel

[Support]

Well, I think you may use the same block/cluster size for RAID, NTFS file system and PrimoCache. That will be the best.

[Axel Mertes]

Well, I think you may use the same block/cluster size for RAID, NTFS file system and PrimoCache. That will be the best.

As I explained, the RAID-6 controller only supports 512 Bytes to 4.096 Bytes = 4 KByte per sector/cluster.
RAID stripes are usually 128 KByte.
Due to the size of the RAID 6 partition (16 * 2 TByte drives, around 25 TByte net) I need to use 64 KByte NTFS formatting as of now, to not explode the RAM usage for indexing.

After all I think using 4 KByte sector/cluster size along with 64 KByte NTFS block size and 128 KByte stripe size sounds OK.


I consider using ReFS instead of NTFS. Is that supported by PrimoCache as well?
Do I need to add each single disk of a storage pool to the caching in order to perform true caching of the ReFS partition?


My point for aiming for ReFS is following:
With NTFS I do risk corruption and unresolveable issues, especially when I consider using write caching or deferred write caching.
ReFS is said to be able to fix its issues itsef. However, we don't know if that is still true with PrimoCache deferred write caching enabled. If I understood ReFS right, it will write a new stream for e.g. the file index, and only if that happens to be successful, it will also change the pointer to the last version of the file index. If writing the file index is finished, but not yet written to physical disks (deferred writes), then in theory we could get a corruption if the machine powers off before the deferred writes can be secured. On the other hand, then this scenario should likely include the pointer change to the latest file index as well, which would mean in the case of the power loss the file index is not officially refreshed, so the self-healing of the drive may work (with the exception of some data loss for the period of deferred writes).

I know that we may use PrimoCache for read only caching, but the performance increase due to (deferred) write caching is outstanding. I also wonder if using e.g. HP z Drive Turbo with its power backed up architecture will help to prevent data loss.

In that context it would strongly make sense to enable write caching to simply run through L2 SSD cache only and bypassing L1 RAM caching optionally. However, what would that imply for the state of re-powering the system?
Valid write data might exist in the SSD, but has not yet been written to HDD (deferred writing in a sense).

Would that be possible?

The performance gain of SSDs over HDDs is still tremendous. Clearly RAM is even faster and deferred writing from L1 RAM to L2 SSD would reduce wear on the L2 SSDs. IMHO its far better to consider using only L2 SSD cache and bypass L1 RAM cache, if I can prevent data loss.

With the upcoming Intel/Micro 3D Xpoint / Crosspoint Optane SSDs (1000x faster than current Flash SSDs) there will be no question to bypass L1 RAM forever, because the Optane memory is non-volatile, so will keep its content after a power loss. For PrimoCache users this is big news IMHO.

See here:

https://newsroom.intel.com/press-kits/i ... -products/
https://newsroom.intel.com/chip-shots/c ... 3d-xpoint/
http://www.computerworld.com/article/30 ... mance.html

First Intel Optane products are scheduled for Q4 this year, so almost "around the corner".

If I can use a SSD that is as fast as my DRAM, then I would bypass DRAM. This solves two issues at once:

1. No more risk to loose data in case of a power fail.
2. No size limitation regarding indexing of cache, as it will be surely significantly cheaper than DRAM (and possibly larger too).

So whatever you have in petto for Version 3 - please consider enabling us to not use L1 RAM cache at all and run only through L2 SSD cache if desired.
If that will work, alongside the ability to recover the SSD only cache from a reboot, then PrimoCache write caching becomes immediately secure and enterprise ready.

Cheers,
Axel

[Axel Mertes]

I just wanted to add that I am currently intensly testing WIndows 2012 R2 server (and soon 2016 server) with Storage Spaces and ReFS. ReFS has a native and ONLY block size of 64 KBytes, which is why I now only use 64 KBytes for any drives block size including the RAM L1 cache. On the storage system it seems to make sense to use the highest block size available until 64 KBytes, in my case 4 KByte. So each block read from the OS will force 16 blocks of 4 KBytes to be read from the storage. Regularly defragmenting in the background should add to the overall performance.