Hacker News Reader

Comment by ALittleLight | Hacker News Reader

I'm not sure I really understood this. If you wanted to delete 10 bytes, couldn't you just read a sector, then copy the sector back sector[10:]?

Edit: then delete the last ten bytes.

View on HN

The unix filesystem api doesn't provide a way to interact with sectors. The primitives are files and the methods available are writing more data, or truncating.

There is no function provided for shifting the byte offset of data in a file.

You can write an entirely new file, of course, but the question has an implicit goal of doing this efficiently.

Does the whole sector thing still make sense for SSDs? Do they still work by sector or can every byte be addressed directly?

The "native" sector size of an SSD is the erasure block size, typically 64KiB.

I'm fairly sure SSD erase block sizes are more like 2 MB or more. Even 8 MB wouldn't surprise me anymore.

current SSDs are page/block oriented, but that's likely to change. (See intel's relatively recent Optane).

Only the last sector is allowed to be partially filled. Every other sector must be fully filled.

Each sector is a fixed size.

At first blush, I don't think this would work quite right because the last ten bytes of the sector would have some content (e.g., zero bytes or some other data from the original sector).

What happens to the last 10 bytes of that sector?

You'd have to do this for every sector in the file or increase potential fragmentation. Alternatively they could support an offset in the beginning, but it might wear out the decide much faster due to lack of alignment. In either case though I feel the capability would be nice to have regardless...

Reply on news.ycombinator.com