Implement support for ACTION_DISK_INFO and ACTION_INFO to a314fs

[Eriond]

Implementing support for the two INFO commands isn't as trivial as one might think at first. This has to do with how the PiDisk volume is presented to the AmigaOS. Normally a volume is the whole logical space on a physical disk, or in the case of a partitioned disk, part of that space. But generally, the AmigaOS assumes that it has exclusive control over that space, and as such it only asks for two key parameters: Total blocks and Used blocks, assuming that the obvious third parameter, Free blocks, can be calculated using the first two. In the case of A314fs, where the presented volume (usually) is a sub-folder on the Raspberry OS disk, the "Total" amount of block presented to AmigaOS isn't necessary equal to the actual amount of blocks on Raspberry OS disk. Or is it? This really depends on what the user is expecting to see when they, for instance open a PiDisk window on the WorkBench. Consider this: The first time you open a PiDisk (after initial installation of A314), the a314shared folder on the RPi is empty. Let's assume you are using a 16GB SD card, where apx. 4GB is used by the Raspberry OS. What should the title bar of the PiDisk window display? a) 0% full, 12 GB free, 0KB in use b) 25% full, 12 GB free, 4GB in use Option "a" may seem intuitive if you're only interested in the Amiga-part of things, but then you have to consider that the free space can suddenly change - regardless of any files you may, or may not have added to the volume, depending on what is happening over at the Raspberry side. Not so intuitive, and maybe confusing. "b" on the other hand makes no sense from a Amiga point of view; "how can there be 4GB in use when I can't see any files?" One way to circumvent the issue, could be to create a real partition on the RPi SD card, that is exclusive to the AmigaOS, and this is where the a314fs.conf would point to. There is (at least) one more thing to consider, and that is how the different sizes (Total, Used) are forwarded to the AmigaOS. It uses a concept of "blocks", not bytes, and accompanying these blocks is a conversion factor called "BLOCKSIZE", indicating number of bytes per block. The variables holding the sizes are of type LONG, ie. 32bits. This puts an upper limit on what can be reported back to the AmigaOS, depending on which blocksize is chosen. As storage media evolves, we see increasingly large SD cards, and it can be tempting to choose a large blocksize to accomodate for a very large Volume size. But this will then be at the expense of "resolution" or granularity; adding small amounts of data to the volume won't cause any changes in the reported used space, thus there is no visible change in usage to the Amiga user.

[cnilsson]

Thought I would put my two cents in!

Regarding free space, in my opinion option b seems like the more reasonable one. Having the amount of used/free space changing is a lot less confusing than having the total size of the volume change. As a bonus I think the implementation would be more straight forward as you don't have to check how much space is used by the a314shared directory, you only care about the whole filesystem.

So, blocksize. Are there any good reasons against going for the native Linux filesystem block size (usually 4kB)? After all, that is the least amount of data a file can occupy on the filesystem anyway so reporting fractions of the native block size makes little sense. With 4kB blocks the max size is 16TB right? Good enough, at least for SD card storage, for a while I think. Famous last words perhaps? :)

[Eriond]

If that is the case (4kB blocks), then it sounds like an obvious choice. I was not aware of it (getting too old, I guess :). And yes, as long as the reason for the missing/occupied space is communicated to the end user, I think option b is the better one.

[Eriond]

Given it some more though, I appreciate the concept of transparency towards AmigaOS even more. Basically, I didn't think that modern OS's used the concept of "blocks" any more, and were completely byte-oriented. So you're completely on target by forwarding the actual values from Linux. I noticed that there are even ready-to-use replies from the statvfs() method (f_blocks, f_bfree and f_bsize). One thing to dig deeper about is how early versions on the AmigaOS handle the possibly large values that could come from modern SD-card sizes. My initial trials with AmigaOS 3.1.4 shows that it can handle values above 4GB without issues. (up to 32GB tested OK)

[niklasekstrom]

Option b sounds good to me too, for the reasons @cnilsson mentioned. os.statvfs() seems like a good function to use.

A question is whether AmigaDOS handles block sizes that are not 512 bytes. I know that a314fs assumes that blocks are 512 bytes in a few places, but that can be changed I guess. Another option is to keep the 512 byte block size and just recompute the number of blocks to match that (512 bytes); this will work for disk sizes up to 1 TB, which may very well be "forever" (or not, in which case the code needs to be changed again later).

[idrougge]

AmigaDOS definitely handles varying block sizes; I have 4 kB blocks on some of my partitions to save memory.

[dcutugno]

96 fixed this