Why is sequential/random R/W stats important when dealing with flash?

[TiskTisk512]

Hi all!

I really don't understand why it is that M.2 NVME and SSD/flash drives altogether are measured with these statistics when there isn't a platter, actuator arm, etc. I see the 'random' r/w at really low speeds for example on the M.2 Samsung 960 Pro... I don't understand...

Thanks!

[Enderman]

Because a storage drive still needs to find the data when it's in random places?

Or do you think it just magically knows where all your data is and instantly goes to the correct place?

 

That's why random reads and writes are so much slower than sequential even though it's still an SSD.

[Sentryy]

it still needs to find the data on the drive which might take a little bit depending on size 

[TiskTisk512]

7 minutes ago, Enderman said:

Because a storage drive still needs to find the data when it's in random places?

Or do you think it just magically knows where all your data is and instantly goes to the correct place?

 

That's why random reads and writes are so much slower than sequential even though it's still an SSD.

OK so I understand the 'random' part of this I guess (sorta, cause it has block addresses which it should be able to access instantaneously and it doesn't have to wait for the platter spin and it doesn't necessarily 'find' these so much as travels to them), but why is sequential read even relevant then? 

[Enderman]

Just now, TiskTisk512 said:

OK so I understand the 'random' part of this I guess (sorta, cause it has block addresses which it should be able to access instantaneously and it doesn't have to wait for the platter spin and it doesn't necessarily 'find' these so much as travels to them), but why is sequential read even relevant then? 

Because when you transfer a single large file then it's not searching randomly for the data, it knows exactly where the data is, so it reads and writes at faster speeds.

Basically sequential = large files (eg videos) and random = small files

[TiskTisk512]

1 minute ago, Enderman said:

Because when you transfer a single large file then it's not searching randomly for the data, it knows exactly where the data is, so it reads and writes at faster speeds.

Basically sequential = large files (eg videos) and random = small files

So why even call it sequential/random? Seems to be a bit disingenuous. More like "large file/small file" speeds... 

[Enderman]

Just now, TiskTisk512 said:

So why even call it sequential/random? Seems to be a bit disingenuous. More like "large file/small file" speeds... 

Because there is no definition of "small file" or "large file".

If you look up the definition of sequential and random you will understand why this is exactly how the tests are done and why those words are used to describe the result.

[TiskTisk512]

2 minutes ago, Enderman said:

Because there is no definition of "small file" or "large file".

If you look up the definition of sequential and random you will understand why this is exactly how the tests are done and why those words are used to describe the result.

OK so actually this article is contradicting you and it's what brought me to ask this question to begin with. If sequential/random I/O are disk concepts, how come I still see those measurements?

[ARikozuM]

Sequential = file can be taken in series starting at 0 going to 10 irregardless of size. When the order of a file is important, sequential will be used.

Random = File can be taken in any order of 0 to 10 and can be stored in any medium until all data is present. 

 

That's the basic gist of it.

[Enderman]

2 minutes ago, TiskTisk512 said:

OK so actually this article is contradicting you and it's what brought me to ask this question to begin with. If sequential/random I/O are disk concepts, how come I still see those measurements?

Take a bunch of small files and copy them from one SSD to another.

Then take a single large video file and do the same.

You will see the video file transfer around 500MBps while the small files will be significantly less, depending on how small they are and where they are stored.

 

That article is wrong.

It is not instant at all.

[TiskTisk512]

1 minute ago, ARikozuM said:

Sequential = file can be taken in series starting at 0 going to 10 irregardless of size. When the order of a file is important, sequential will be used.

Random = File can be taken in any order of 0 to 10 and can be stored in any medium until all data is present. 

 

That's the basic gist of it.

Can you give me a real-world example/use case here?

[TiskTisk512]

10 minutes ago, Enderman said:

Take a bunch of small files and copy them from one SSD to another.

Then take a single large video file and do the same.

You will see the video file transfer around 500MBps while the small files will be significantly less, depending on how small they are and where they are stored.

 

That article is wrong.

It is not instant at all.

OK so I found a reply on a Dell support site that kinda supports what you're saying, but man it has been a lot of searching to get there. You're right, but this goes into detail about why:

 

When people talk about sequential vs random writes to a file, they're generally drawing a distinction between writing without intermediate seeks ("sequential"), vs. a pattern of seek-write-seek-write-seek-write, etc. ("random").

The distinction is very important in traditional disk-based systems, where each disk seek will take around 10ms. Sequentially writing data to that same disk takes about 30ms per MB. So if you sequentially write 100MB of data to a disk, it will take around 3 seconds. But if you do 100 random writes of 1MB each, that will take a total of 4 seconds (3 seconds for the actual writing, and 10ms*100 == 1 second for all the seeking).

As each random write gets smaller, you pay more and more of a penalty for the disk seeks. In the extreme case where you perform 100 million random 1-byte writes, you'll still net 3 seconds for all the actual writes, but you'd now have 11.57 days worth of seeking to do! So clearly the degree to which your writes are sequential vs. random can really affect the time it takes to accomplish your task.

The situation is a bit different when it comes to flash. With flash, you don't have a physical disk head that you must move around. (This is where the 10ms seek cost comes from for a traditional disk). However, flash devices tend to have large page sizes (the smallest "typical" page size is around 512 bytes according to wikipedia, and 4K page sizes appear to be common as well). So if you're writing a small number of bytes, flash still has overhead in that you must read out an entire page, modify the bytes you're writing, and then write back the entire page. I don't know the characteristic numbers for flash off the top of my head. But the rule of thumb is that on flash if each of your writes is generally comparable in size to the device's page size, then you won't see much performance difference between random and sequential writes. If each of your writes is small compared to the device page size, then you'll see some overhead when doing random writes.

Now for all of the above, it's true that at the application layer much is hidden from you. There are layers in the kernel, disk/flash controller, etc. that could for example interject non-obvious seeks in the middle of your "sequential" writing. But in most cases, writing that "looks" sequential at the application layer (no seeks, lots of continuous I/O) will have sequential-write performance while writing that "looks" random at the application layer will have the (generally worse) random-write performance.