OSDev.org

rdos wrote:True, but if you use FAT, then logical sectors in the FS are still 512.

First off, I personally wouldn't use FAT, as it is a nightmare from a security and stability standpoint, and really is only useful to transfer data between computers. Also, FAT doesn't depend on 512 byte sectors, as in theory, the bytes per sector field of the BPB allows for non standard sector sizes

rdos wrote:True, but if you use FAT, then logical sectors in the FS are still 512.

If you align the clusters to physical sectors, you can still cache physical sectors. Windows adds padding to align the clusters to sector boundaries when formatting disks.

Also, the logical sector size in FAT matches the logical sector size of the disk, so it'll be 4kB on disks that don't provide 512-byte sector emulation.

Octocontrabass wrote:

rdos wrote:True, but if you use FAT, then logical sectors in the FS are still 512.

If you align the clusters to physical sectors, you can still cache physical sectors. Windows adds padding to align the clusters to sector boundaries when formatting disks.

Also, the logical sector size in FAT matches the logical sector size of the disk, so it'll be 4kB on disks that don't provide 512-byte sector emulation.

That's what I plan to do too, as having non-aligned clusters means that fragmented files cannot use a simple memory mapping, rather needs many short blocks, where the first and last page must be marked as read-only to the application since part of it might not belong to the file. However, I need to support discs where clusters are not aligned to 4k blocks.

nexos wrote:

rdos wrote:True, but if you use FAT, then logical sectors in the FS are still 512.

First off, I personally wouldn't use FAT, as it is a nightmare from a security and stability standpoint, and really is only useful to transfer data between computers. Also, FAT doesn't depend on 512 byte sectors, as in theory, the bytes per sector field of the BPB allows for non standard sector sizes

I think FAT is ok for many uses. Its main problem is that it has poor support for large partitions and that it doesn't support large files.

Turns out that I have a single unused bit in the 64-bit cache entry. The lower 12 bits are unused because of 4k page alignment. The lower 8 bits are individual write request bits for the sectors, bit 8 is present bit, bit 9 is valid bit, bit 10 is used for LRU discarding and I can use bit 11 as an error bit. I assume that 48-bit physical addresses will be enough to support, and this gives me 16 more unused bits. These are used as a bitmap for requests when waiting for data (there are 15 possible request ids + a generic request list id) and for reference counting when the cache entry is in use.