Formatting SSD, interesting info

I got my camera today



Since I got my Sandisk Extreme 480 a few weeks ago I've been reading about setting your Allocation Unit Size higher (in the format options) when you're working with large data chunks for better performance. Since the BMCC records 5MB raw files or potentially huge ProREs/DNxHD files, I formatting my SSD to exFat and used 32000K as the allocation size.

It was exciting to use the camera for the first time, but disappointing to see how long it took to stop recording. Also, it wouldn't playback RAW files, just prores. Thinking the error was with the user, I went back and reformatted my SSD with lower and lower allocation unit size options until I was at 128. This gave the best performance. It's also what the default option would pick. Now all the camera function work and work instantaneously!

So if you're curious about that setting, leave it alone

Now the real fun begins!

sean

I got my camera today

Since I got my Sandisk Extreme 480 a few weeks ago I've been reading about setting your Allocation Unit Size higher (in the format options) when you're working with large data chunks for better performance. Since the BMCC records 5MB raw files or potentially huge ProREs/DNxHD files, I formatting my SSD to exFat and used 32000K as the allocation size.

It was exciting to use the camera for the first time, but disappointing to see how long it took to stop recording. Also, it wouldn't playback RAW files, just prores. Thinking the error was with the user, I went back and reformatted my SSD with lower and lower allocation unit size options until I was at 128. This gave the best performance. It's also what the default option would pick. Now all the camera function work and work instantaneously!

Congratulations on getting your camera.

Was your final (default) allocation unit 128KB or 128 bytes?

Interesting experiment. I wonder if setting the allocation unit to 32000KB (32MB) would mean each DNG raw image of 5MB would occupy 32MB space on the SSD or if the write operation would only occur approximately every 6 raw images?

Rick Lang
Sent from my iPad using Tapatalk HD

I wonder if setting the allocation unit to 32000KB (32MB) would mean each DNG raw image of 5MB would occupy 32MB space on the SSD or if the write operation would only occur approximately every 6 raw images?

The way most (all?) file systems work, is that the smallest size of a file is the bigger of the actual file size and the block size (allocation unit). So by setting the block size to 32MB, you actually blow up each 5MB DNG to a 32MB File. This is obviously a very bad idea... even setting it to 4MB would be bad as the files would then be 8MB in size (two blocks needed for a 5MB file). The lower the block size, the less "wasted space" per file you have.

In the past, often the issue was that the amount of blocks that were addressable were limited, so making them bigger worked around that issue. This isn't really the case here, so I would definitely stick to the "default" block sizes that are offered by the system.

Sean, Congratulations on getting your camera.

[CaptainHook]

Congrats Sean!! Enjoy.

I wonder if setting the allocation unit to 32000KB (32MB) would mean each DNG raw image of 5MB would occupy 32MB space on the SSD or if the write operation would only occur approximately every 6 raw images?

The way most (all?) file systems work, is that the smallest size of a file is the bigger of the actual file size and the block size (allocation unit). So by setting the block size to 32MB, you actually blow up each 5MB DNG to a 32MB File. This is obviously a very bad idea... even setting it to 4MB would be bad as the files would then be 8MB in size (two blocks needed for a 5MB file). The lower the block size, the less "wasted space" per file you have.

In the past, often the issue was that the amount of blocks that were addressable were limited, so making them bigger worked around that issue. This isn't really the case here, so I would definitely stick to the "default" block sizes that are offered by the system.

I understand this concept...especially for DNG files....but shouldn't your performance increase with long form video formats? For example, a 50GB ProRes file? It did not seem to help the capture or playback of those files either.

I know this would be more prevalent on a spinning disk over an SSD, where fragmentation overhead can slow down throughput, however it SHOULD provide a longevity boost for SSD, as you are performing fewer write operations. (the cause of wear and eventual failure in SSDs)

So if you're writing massive files continuously for the life of the SSD, a larger allocation bit size should theoretically increase the lifespan of your SSD. 50GB files written in 1563 operations compared to 390625 operations. (32MB vs 128K)

What I don't get is why does the BMCC have such a problem with the larger allocation size? It's not a problem once I mount the SSD on my PC....it transferred the ProRes files as fast or even 2% faster than the lower allocation.

Anyway...maybe I read too much and I should just shoot more

So if you're writing massive files continuously for the life of the SSD, a larger allocation bit size should theoretically increase the lifespan of your SSD. 50GB files written in 1563 operations compared to 390625 operations. (32MB vs 128K)

What I don't get is why does the BMCC have such a problem with the larger allocation size? It's not a problem once I mount the SSD on my PC....it transferred the ProRes files as fast or even 2% faster than the lower allocation.

Anyway...maybe I read too much and I should just shoot more

Definitely reading too much! Our thorough understanding of convention spinning hard disk tracks may be a hindrance on understanding the ins and outs of the on-board data controllers of an SSD.

Rick Lang
Sent from my iPad using Tapatalk HD