When an image is protected (thus can't be deleted in camera), is it still protected when the card is connected to the computer or does it only work while the card is into the camera?
No. Protected images are only protected from erasure on the camera. They can be deleted on a computer, and will be deleted if you format the card (either on a computer or on the camera).
The answer to that, at least in the case of this video is that I have a degree in computer engineering, and was involved in an aborted attempt at writing a FAT32 implementation as part of my senior design project. So I've kind of gotten deeper into at least some of what I covered in this video in a way that I don't expect many people will have.
I think your assessment is correct, but mostly flawed. You assume the in-memory chunks left over are the size of the file, but that depends on how the filesystem is formatted. It's one of the options Windows asks you to determine the chunk size. So at worst you'd be filling 1 byte of that chunk, at most you lose a chunk. Also the fact that it's flash storage and not hard disk, it's really not a problem to retrieve/write the data. Thirdly, you assume flash storage works by writing in contiguous chunks, but that's really not how it works at all. Harddrives work like that, but not flash storage.
> You assume the in-memory chunks left over are the size of the file, but that depends on how the filesystem is formatted. It's one of the options Windows asks you to determine the chunk size. So at worst you'd be filling 1 byte of that chunk, at most you lose a chunk. Context… We’re talking about cameras and images here, not arbitrary data on an arbitrary SSD. You’re not going to have a 1 byte file on a camera. The point of the example is to illustrate how fragmentation occurs when deleting a file. There’s no benefit to adding needless complexity by introducing the idea that well several files could be written in the freed space, and then at the nth file we finally get a fragment. Also, changing the cluster size is largely about balancing sequential write performance (big clusters have big sequential LBA ranges which makes them big sequential IOs) with wasted space for files smaller than the cluster size. FWIW, exFAT was designed to a large degree with media storage in mind. Hence the relatively large default cluster sizes (128KB - 1MB for cars in the 32GB to 4TB range). 128 KB large enough to be efficient when writing, while not being so large that when paired with 3-50MB images the wasted space is significant. With large cards 1TB+, you’re most likely talking about video, and with multi-GB files being expected in that case, the 512K-1M cluster size still really isn’t a problem. > Also the fact that it's flash storage and not hard disk, it's really not a problem to retrieve/write the data. It’s not really a problem to read/write data to a hard disk either… What I think you’re trying to argue here is that there’s no performance penalty for small and random I/O on flash. Or at least that it “doesn’t matter” because the penalty is much lower. The reality is there still is a performance penalty for small and random I/Os on flash media. You can see this in any benchmark for flash media, though not that many people benchmark SD and CFE cards. I have, for a 95MB/s 128GB UHS-1 SanDisk card, sequential 1MB writes can completely saturate the interface at 95MB/s. 1MB random writes will reduce throughput to somewhere around 50-70MB/s depending on the platform and card’s trim state. Even doing semi-sequential writes (16- 1M blocks before a new random address) reduces the throughput by more than 10%. Is that good enough? Probably, but I said as much in the video. You’re not likely to have issues with good flash that’s much faster than what you actually need. However, highly fragmented flash that’s only marginally faster than the minimum requirements certainly could have problems. > Thirdly, you assume flash storage works by writing in contiguous chunks, but that's really not how it works at all. Harddrives work like that, but not flash storage. First, no, I’m not assuming anything about how the internals of the flash work. I don’t care, nor do I have to. It’s already been empirically shown that random and semi-random writes are slower than contiguous ones. The details beyond that aren't really relevant, and don't do anything to explain things more clearly. Second, you’re assuming a lot about what and how I’m approaching the discussion here. In the video I’m talking generally at the file system level, as I think it’s a good compromise between not having overwhelming complexity while still describing the potential problems clearly. I’m well aware of what’s going on at the lower levels, but I don’t think adding that in to the discussion adds any value beyond making it even more confusing.
When an image is protected (thus can't be deleted in camera), is it still protected when the card is connected to the computer or does it only work while the card is into the camera?
No. Protected images are only protected from erasure on the camera. They can be deleted on a computer, and will be deleted if you format the card (either on a computer or on the camera).
Sometimes I randomly wonder how do you know so much. Then I asked myself Do I want to know? Lol just kidding Yes I do
There surely is a video in which he explains how he knows all this 😉
The answer to that, at least in the case of this video is that I have a degree in computer engineering, and was involved in an aborted attempt at writing a FAT32 implementation as part of my senior design project. So I've kind of gotten deeper into at least some of what I covered in this video in a way that I don't expect many people will have.
@PointsInFocus ... And is also very interesting to us! Thanks for sharing your knowledge 👍🤓👍
I think your assessment is correct, but mostly flawed.
You assume the in-memory chunks left over are the size of the file, but that depends on how the filesystem is formatted. It's one of the options Windows asks you to determine the chunk size. So at worst you'd be filling 1 byte of that chunk, at most you lose a chunk.
Also the fact that it's flash storage and not hard disk, it's really not a problem to retrieve/write the data.
Thirdly, you assume flash storage works by writing in contiguous chunks, but that's really not how it works at all. Harddrives work like that, but not flash storage.
> You assume the in-memory chunks left over are the size of the file, but that depends on how the filesystem is formatted. It's one of the options Windows asks you to determine the chunk size. So at worst you'd be filling 1 byte of that chunk, at most you lose a chunk.
Context… We’re talking about cameras and images here, not arbitrary data on an arbitrary SSD. You’re not going to have a 1 byte file on a camera. The point of the example is to illustrate how fragmentation occurs when deleting a file. There’s no benefit to adding needless complexity by introducing the idea that well several files could be written in the freed space, and then at the nth file we finally get a fragment.
Also, changing the cluster size is largely about balancing sequential write performance (big clusters have big sequential LBA ranges which makes them big sequential IOs) with wasted space for files smaller than the cluster size.
FWIW, exFAT was designed to a large degree with media storage in mind. Hence the relatively large default cluster sizes (128KB - 1MB for cars in the 32GB to 4TB range). 128 KB large enough to be efficient when writing, while not being so large that when paired with 3-50MB images the wasted space is significant. With large cards 1TB+, you’re most likely talking about video, and with multi-GB files being expected in that case, the 512K-1M cluster size still really isn’t a problem.
> Also the fact that it's flash storage and not hard disk, it's really not a problem to retrieve/write the data.
It’s not really a problem to read/write data to a hard disk either…
What I think you’re trying to argue here is that there’s no performance penalty for small and random I/O on flash. Or at least that it “doesn’t matter” because the penalty is much lower.
The reality is there still is a performance penalty for small and random I/Os on flash media. You can see this in any benchmark for flash media, though not that many people benchmark SD and CFE cards.
I have, for a 95MB/s 128GB UHS-1 SanDisk card, sequential 1MB writes can completely saturate the interface at 95MB/s. 1MB random writes will reduce throughput to somewhere around 50-70MB/s depending on the platform and card’s trim state. Even doing semi-sequential writes (16- 1M blocks before a new random address) reduces the throughput by more than 10%.
Is that good enough? Probably, but I said as much in the video. You’re not likely to have issues with good flash that’s much faster than what you actually need. However, highly fragmented flash that’s only marginally faster than the minimum requirements certainly could have problems.
> Thirdly, you assume flash storage works by writing in contiguous chunks, but that's really not how it works at all. Harddrives work like that, but not flash storage.
First, no, I’m not assuming anything about how the internals of the flash work. I don’t care, nor do I have to. It’s already been empirically shown that random and semi-random writes are slower than contiguous ones. The details beyond that aren't really relevant, and don't do anything to explain things more clearly.
Second, you’re assuming a lot about what and how I’m approaching the discussion here. In the video I’m talking generally at the file system level, as I think it’s a good compromise between not having overwhelming complexity while still describing the potential problems clearly. I’m well aware of what’s going on at the lower levels, but I don’t think adding that in to the discussion adds any value beyond making it even more confusing.