!HForm errors

That sounds ideal. I’m looking forward to using the missing 30GB on my SD card.

Would it be possible to have various SDFS disk images for standard sizes of SD card that can be copied to them using other OSs? If their content was all zeros (or all ones) apart from the filesystem data, they’d all compress down to a similar, managable, size.

Not that would exactly fill the SD card. Each brand has slightly different sizes so you would have to make it slightly smaller than the cheapest card of that size. Hence the standard RISC OS distro is 1875MB = 1920MB = 1966,080,000 bytes which compresses to 122MB (it includes the whole distro). This has the advantage that it is a file size that all versions of RISC OS can handle and is sufficiently less than 2GB that even the cheapest 2GB card is large enough to contain it.

Filecore does not lend itself to resizing the card and retaining the contents as can be done on Linux. Resizing the card will wipe it. Buy !SystemDisc which will make the right partition table entries to protect the filecore data and then populate the FAT and filecore partitions leaving the file Boot:Loader itself untouched, except to copy data into its image filing system.

+1 for SystemDisc it is excellent, £15 well spent. And one gets to create one’s own disc image.

This has the advantage that it is a file size that all versions of RISC OS can handle and is sufficiently less than 2GB that even the cheapest 2GB card is large enough to contain it.

Sadly not, back in the early days we found at least one (reputable) brand of 2GB SD card at work which the standard image did not fit on to! Luckily, once you’ve written it to one card, you can copy the whole lot off and then just make up cards of any size using SystemDisc as required.

Personally, I’d like to see SystemDisc being a free utility provided for download so anyone can use sensible sized SD cards (where do you get 2GB microSD cards from these days?) without having to buy third-party software, but I guess there’s no incentive for ROOL to acquire it and make it freely available.

+3 for !SystemDisc very useful for imaging SSD and SD devices. You can buy it from Elesar in the software section. http://shop.elesar.co.uk/

Sadly not, back in the early days we found at least one (reputable) brand of 2GB SD card at work which the standard image did not fit on to!

I think the standard RISC OS image was reduced multiple times to fit on the “smallest 2 GB SD card ever seen in the wild”.

Would be good to have a service available to “create minimum RISC OS image for system x with OS version y for SD card sized z” in the absence of a live Filecore resizer.

in the absence of a live Filecore resizer.

I believe the phrase is “non trivial”. ;)

How about having a ~150 MB FAT partition and nothing else? On first boot it’ll run something similar to HForm/SystemDisc/PartMgr and automatically create a FileCore partition that fills the rest of the card, then unzips a “recovery image” onto the new partition and reboots.

Yes, that’s 100 MB more “wasted” space than we have now, but cards are getting bigger and it also allows for a “factory reset” without redownloading anything.

Of course, there’s still the whole “need a developer to build it” angle :)

Could be doable with a very specific formatter.

You realise, I hope, that the FileCore part is made first (with HForm) and the FAT part is made afterwards (with SystemDisc), so you’d need something that can set up a FileCore disc of variable size around the FAT partition, and then me that into the FileCore part without otherwise touching it, and then (probably reboot and) extracts the boot stuff to the FileCore part.

It must be like harddisc4, it cannot be a recovery image. The big problem with FileCore, and why you can’t just extend the disc size, is that the maps are held in the middle of the disc. Altering the size moves the “middle”.

You realise, I hope, that the FileCore part is made first (with HForm) and the FAT part is made afterwards (with SystemDisc)

I haven’t used SystemDisc for a while so I’d forgotten that. It complicates things a bit!

It must be like harddisc4, it cannot be a recovery image.

I didn’t use the right word there. I just meant a zip file that can be extracted, not an actual image :)

You realise, I hope, that the FileCore part is made first (with HForm) and the FAT part is made afterwards

It actually makes more sense to lay down the FileCore structure after the MBR and FAT to avoid having to retrospectively change FileCore.

In reality, they can be created in any order provided various restrictions are met.

The filecore partition ‘knows’ it is the only show in town and thus starts at the beginning of the SD card (well just further enough on from address zero not to trample on any partition table that might exist, fortunately built in to the filecore system from day one) and extends over the space it was set up to use, let that be Y. The FAT partition, of size X, is then cunningly created inside this space at the start (the map is in the middle of filecore space) with an image filing system file in the filecore partition pointing to it (i.e. to the start of filecore space). Thus the partition table (which !SystemDisc creates and filecore ignores) records a FAT partition of size X followed by a filecore partition of size Y-X. This means that you can format the FAT partition on Windows (with size adjustment off) without affecting this delicate linkage.

In principle therefore, it would be possible to create the filecore data around a pre-existing FAT partition on an otherwise blank SD card with the filecore size filling the card and with a file of type ‘DOS’ of the correct size pointing to the FAT partiton. A second entry can then be added to the partition table to protect the filecore data. On first boot the filecore partition could be created and then populated from a zip file (or Util file) in the FAT partition.

Making filecore ‘aware’ of partition tables might bring this convenient state of things to an end.

means that you can format the FAT partition on Windows

But NOT Android. It ignores the partition size and will format the entire media.

Thank god for DiscKnight…

Not sure why the SD card format has to be so complicated.

All I did when creating mine was to use !hform to format the card with the size – 64MiB. Then I created a MBR with a partition table containing two entries. One for the filecore and the other for a FAT partition using the reserved 64MiB at the top of the card. Then format that partition and copy the boot files to it.

Not sure why the SD card format has to be so complicated

Quite. The only reason I could think of would be to facilitate !Boot.LOADER pointing to the FAT partition, or somehow related to NOOBS.

I’ve been considering both options over the past week and am swaying toward putting the FAT at the end to avoid all the complications of embedding it into the FileCore area, although that would require bundling FAT32FS with Partition Manager, or writing my own FAT filesystem.

using the reserved 64MiB at the top of the card.

Some bootloaders are not as competent as being able to read partition tables and the like.
The Beagle, for instance, expects not only to see a FAT filesystem as the first thing on the card, it also expects to see the MLO file first in the list.
Further to that, what does Windows do if given media where FAT is at the end?
And, as has been mentioned, RISC OS itself.

to facilitate !Boot.LOADER pointing to the FAT partition

I think it’s the duality of having the FAT part appear first, plus the usefulness of being able to access it as an image file. It’s just a huge pile of luck that the important stuff required by both filesystems didn’t trample over each other.

Not sure why the SD card format has to be so complicated.

Not really that complicated at all.

But the reason is simple. The SDcard has to be seen by the Pi bootloader as a FAT disc and then the same SDcard has to be seen by RISC OS as a FileCore formatted disc.

Because RISC OS does not support partitionss, some jiggery pokery was needed. A brilliant solution in its day and so far nobody has come up with a better solution.

think it’s the duality of having the FAT part appear first, plus the usefulness of being able to access it as an image file

The Boot Loader is not an image file. The contents are distinct files.

Of course, having said all that, the simpler (but more expendive) solution is to have just the Boot Loader files on a standard SDcard and RISC OS on a FileCore formatted USB SATA (or mSATA) drive.

the simpler (but more expendive) solution

Also the solution less likely to result in a dead SD card down the line, unless you splash out on a high endurance card, or don’t use your Pi all that much.

The Boot Loader is not an image file.

It is mapped into the filesystem as a DOS image file, accessible using DOSFS (etc).

The contents are distinct files.

That’s how it appears because RISC OS got that bit right in 1992.
They cannot be individual files in a directory on a FileCore partition as FileCore knows nothing about FAT. So it’s handled by DOSFS that does know.
(easy way to tell – look at the file info for the Loader directory, it’ll be many megabytes in size)

less likely to result in a dead SD card down the line

All media eventually dies.

That being said, when purchasing media for my Pi, I pick midrange process. I don’t need the expensive cards as those are for things like writing 4K video in realtime. I don’t buy the cheap ones because, seriously, if you can get 16GB for €5, it’s clearly only useful for stuff you don’t care about…

My current card has been running a mostly 24hr system for many years (when did I first get that Pi 2?), and that’s with a web server that writes log files, and a weather recorder making recordings every five minutes.

Just stay away from the cheap cards.

when did I first get that Pi 2?

Oh my. August 2017. I think I’ll see what brand of card is installed and get a replacement. Hell, ~6 years is more than I’ve had from some spinning rust.

and that’s with a web server that writes log files

I presume it’s writing new files, not overwriting old ones? Or not doing it too frequently?

I use high speed cards for my camera, but I don’t feel the need for high endurance there – I just don’t delete images to save space, and just reformat the beast when it’s full (after downloading the last pics, obviously 8~). But I do use high endurance for the dashcams, since that gets overwritten after every fifteen hours or so of driving.

I presume it’s writing new files, not overwriting old ones?

It adds to the existing file, and when it gets to a certain size, rotates them so I have 3 (I think) files.

Or not doing it too frequently?

Between ten and several hundred requests per day. It depends upon whether or not my IP turns up in the eyes of one of those annoying bots that tries looking for weak phpMyAdmin stuff.

But I do use high endurance for the dashcams, since that gets overwritten after every fifteen hours or so of driving.

I said a while back, I’ve been driving since November 2019 in a car that does 45kph, and I’ll soon be coming to a major service soon so I think it’ll be something around 30,000km I’ve driven (about 12,000 in Caoimhe alone so far). Going to work and back adds up.
The camera dumps around three to four hundred megabytes per minute. Let’s assume 350MB.

A back of the envelope calculation (thus probably wrong because you know what I’m like with maths) says it’s about 40,000 minutes. I’ll add another 4,000 to cover the two large 30kph zones on the way.
44,000 minutes of driving, at 350MB/min, is 15,400,000 MB. That’s 15.4 terabytes. That’s how much I’ve dumped onto my dashcam’s µSD card. It’s just a generic Verbatim class 10 16GB SDHC. No high endurance, just a decent brand.

The big problem with FileCore, and why you can’t just extend the disc size, is that the maps are held in the middle of the disc. Altering the size moves the “middle”.

Being in the middle is the least of the problems; any significant partition size change which in would involve altering the allocation unit size, means absolutely everything on the disc has to be re-written. The entire map contents would have to be regenerated, the map id in every directory entry needs to be updated, and to really take the biscuit, every file and directory needs needs to be shifted to a new sector alignment.

It’s easier, quicker and safer to format a new card and copy everything over.

When it comes to wear on SD, its the size of the blocks being written. A modern SD can internally have an erase block size in the MB, which means small files cause blocks to be read/erased/rewritten hundreds of times. For cameras and the like, the wear is lower as they tend to write large files via DMA, but for filesystems like RISC OS that work in very small blocks the wear is incredibly high.

SSD generally have a smaller erase block size, so wear is immediately reduced as it’s not erasing blocks as often.