File system improvements (Step 1)

This bounty represents the first steps along the road of bringing the RISC OS file system completely up-to-date. There will be a set of these bounties, but only one will be published at any time. It is essential to the future of RISC OS that we have a file system which is able to cope with modern drives, formats, file sizes and so on.

Overview

This bounty looks to remove two key limitations to the FileCore module which is used by ADFS to access hard discs, SCSIFS to access USB memory sticks, as well as other 3rd party interfaces.

With the advent of much larger multimedia files and solid state storage this ceiling is being hit more regularly – for example DOS/Windows formatted USB memory sticks over 2GB are commonplace, as the DOSFS filing system relies on FileCore for reading and writing.

The ‘on-disc’ format allows for files up to 4GB, but the implementation restricts this to only 2GB. By removing this restriction the file size limit is increased without the need to reformat preexisting discs.

For developers, the various disparate strands of documentation will be pulled together into a replacement chapter for the programmer’s reference manual, as well as ensuring ‘fsbash’ exercises the extensions. This tool and clear understanding will be essential for future, more fundamental, changes to the filing systems.

Technical detail

Why 2G? Any number of assumptions could have resulted in the need for a 2G clamp, likely candidates are storing flags in the top bits of offsets, doing signed comparisons, terminating background transfer lists with any negative number rather than -1.

Where to go for documentation? PRM2, PRM5a, the Ursula FileCore upgrade functional specification. Scattering the detail around does nothing but cloud FileCore in a fog of mystery and misinformation – collecting this together in a single, revised, PRM chapter is essential. For example, the calculations on
PRM 5a-172 are mostly wrong!

How to test this? There is already a tool called ‘fsbash’ which exercises all of the filing system entry points and data integrity, so this can be largely reused. However, checking for the specific boundary cases (eg. crossing from a non-top-bit set file extent to one > 2G) will give confidence that any changes aren’t going to result in loss of user data.

What type? Unrecognised media is offered to image filing system clients for recognition, the most obvious being DOSFS. As it uses FileCore for disc I/O it inherits the 2G limit currently, but is likely to have some hidden gremlins through use of ‘int’, a signed type, rather than uint32_t.

Deliverables

These are subject to agreement with ROOL, but are expected to look something like:

• Revised PRM chapter describing FileCore at the disc and behavioural level
• Updated ‘fsbash’ exercising tool
• Updated FileCore supporting files up to 4GB and sectors up to 4096 bytes, the increased sector size support will allow a factor x8 increase in the biggest supported hard disc (up to 2TB)
• Updated DOSFS able to access memory sticks and partitions up to 4GB

Donations	11
Total	£720.00
State	Completed
Help	More information about the bounty scheme Bounty scheme discussion forum

All bounties