What is it with SDFS?

I can’t shake the feeling that something’s seriously amiss with SDFS and/or RISC OS 5.21 on the Raspberry Pi.

With each and every new SD card on my Raspberry Pi, checkmap sooner or later reports “Map inconsistent with directory tree”… even if the OS never was force reset or ever something remotely file-system-taxing was done with it.

Now I wonder if I’m the only one with this problem and something is wrong with my Pi, or if others have these issues, too. I experienced the problem on two different Pi’s with two different power supplies and a whole lot of different SD cards… I’m now back on my trusty Risc PC as main development machine, because there the file system never ever failed me…

Kind regards,
Stephan

I can’t shake the feeling that something’s seriously amiss with SDFS and/or RISC OS 5.21 on the Raspberry Pi.

I’m saying nothing. ;-)

Now I wonder if I’m the only one with this problem and something is wrong with my Pi, or if others have these issues, too.

Me? Problems? Nah. Nothing wrong at all.

• https://www.riscosopen.org/forum/forums/2/topics/2313
• https://www.riscosopen.org/forum/forums/5/topics/2601

The problem would be a lot more tolerable if the OS had a way of recovering from its own cock-up. I understand that ROOL don’t want to step on the toes of Druck and his DiscKnight, but – really – name me an OS that doesn’t come with a basic file system recovery tool. I emphasise basic. DiscKnight does a lot of stuff. RISC OS really only needs to have *CheckMap do something better than say “map inconsistent with directory tree” and bail out, leaving you a damaged unusable file system. At the very least, it should validate both maps and offer to copy the one that matches the directory structure. Or, better yet, scan through the file system and attempt to rebuild the map. Anything other than be utterly useless. I’m not asking for a total fix it, leave the heavy lifting to DiscKnight. I’m just asking for a file system to be capable of recovering itself from a situation that appears to be more commonplace than in the past.

I’m now back on my trusty Risc PC as main development machine, because there the file system never ever failed me…

Yup. I can second that. Just switched on my RiscPC this weekend. Maybe the first time in half a decade? Needed a CMOS reset power up, but the hard discs and the file system worked flawlessly. I think I’ve only encountered two failures with my RiscPC. The first was when I dropped a screwdriver on the hard disc (instant death) and the second was when I formatted the wrong hard disc. Okay, I had the one I formatted backed up to CD-R, but it gave my bladder a workout for sure!

Either that, or the two of us are the unlucky ones that see stuff like this:

(note in this case that the error was reported by !Zap; I edited some stuff and pressed F3 to save, and somewhere along the line the machine broke itself!)

Either that, or the two of us are the unlucky ones that see stuff like this:

Maybe just edit the messages file?
Perhaps changing it to “One copy of map broken (kiss your data goodbye)” would be a better fit?

Edit: Less cynical wit? Sympathy please I’ve spent all day in meetings relating to a contract. Just one. I’m a techie not a paper shuffler. I hope…

If you are worried about SDFS, SD cards or your Pi power supply, just use an externally powered USB harddisc or a hub-powered one. Still a lot better than a Risc PC. I use a hub-powered 250 GiB disc since day one of the BeagleBoard port and never had a problem.

Edit: Less cynical wit? Sympathy please I’ve spent all day in meetings relating to a contract. Just one. I’m a techie not a paper shuffler. I hope…

Either your company is in trouble, or you are really high up the food chain.

The impression I got was that management did all they could to keep techies away from meetings. Instead, they and sales drones would happily promise the moon on a stick by next Wednesday… and they’d hand the required specification to the techs on Tuesday.
“The company needs it tomorrow so you don’t have time to complain that this is bul****t, contradictory, and requires technology that mankind has not yet invented – so shut up and make it happen – and note that employees are forbidden from reading anything by that notoriously subversive author Simon Travaglia. Any questions? No? Righty-ho, you have this entire system to create by tomorrow. I shall mark you down as having volunteered to do unpaid overtime, shall I?”…

Either your company is in trouble, or you are really high up the food chain.

Of course on the first (it’s the NHS and the Tories are in government).
Don’t think so on the second¹, my bank account would be healthier if that were true.

and note that employees are forbidden from…

Having coffee makers in the office, having fridges in the office, kettles etc².

¹ Part of the furniture known to executive directors, so insufficiently anonymous

² Almost every office in the IT building has either a coffee maker or a kettle or a fridge. Ours has two coffee makers and a fridge. The kitchen area acquired a microwave. The estates guys shrugged and safety tested the lot and then moved on to another building. Of course they could have upset us.

Stephan: Yours is not a common experience. Despite using many different Pi’s in our work. I can’t recall ever getting a ‘Broken Map’. Whilst underpowered/dodgy PSUs are often sited as the cause of all Pi ills, I’d say it is well over 90% likely to be the cause of your problem. What power rating are your PSUs?
Are they the same model?
Are the SD cards the same make/model?
What else are you pluging into your Pi?
HDMI to VGA adaptor?

Ours has two coffee makers and a fridge. The kitchen area acquired a microwave. The estates guys shrugged and safety tested the lot and then moved on to another building.

They were probably found to be year 2000 compliant so not an issue.

Fond memories of working for the NHS.

Have you checked the working / non-working card list (oder diese)?
Have you overclocked your RPi? I have any cards working with 700MHz but not with 800MHz (also the MAP-error). If I use this cards in external cardreader… no errors found.

Thanks for all the answers!
The PSUs are both the same type, rated at 5V, 1200mA, there’s a HDMI-to-DVI cable, and a 4 port USB hub which hosts keyboard, mouse and an 16gb usb stick. I used different SD cards from Transcend, I’ll have to look up the exact type specifier…

Kind regards,
Stephan

and a 4 port USB hub which hosts keyboard, mouse and an 16gb usb stick.

Is this an externally powered hub? I always use hubs with their own psu, and never had any trouble (including using SSDs as main storage).

No, the hub is powered via USB. I’ll buy an externally powered hub and stress test the two Pi’s over the weekend (one with the powered hub, the other with the old one). I’ll let you know how that went…

I suggest trying ‘no hub’ as well.
Trying a different brand of PSU would also be useful, just in case yours are not regulated. Battery charging PSUs don’t need to have a ‘clean’ output, Pis do.
n.b. Can anyone thing of a way writing the plural of Pi i.e. not Pis, it just looks so wrong!

IMHO it’s Pi singular and plural – same logic as sheep.

RPi forum fun

2xPi isn’t written 2xPis. Another point you should always have a clean output of your pis, otherwise you should see the doctor – and using PSU’s or batteries isn’t going to clear that up, but it sure sounds painful! ;-)

I thought Pis was a famous mannequin in Brussels.

Pretty sure that the Pi should always be used with a powered hub. Connecting an unpowered hub is probably going to give problems.

All I can say is that I’ve been using Pis with RISC OS for 18 months so far and haven’t experienced any file system corruption on SDFS at all—and that’s including the need for some hard resets at times.

Hi all, thought I’d keep you posted on my progress…
So I got myself a new PSU and I got rid of the USB-powered hub.
Also, I wrote a little file system stress test in BBC Basic that repeatedly creates and deletes 500 files an does a *CheckMap every for every 100 files that are created.
As it turns out, the culprit was not only a faulty PSU but also two faulty SD cards. With the old PSU, none of my cards reached over 1200 generated files, always breaking with “map inconsistent” or “disc error”.
With the new PSU, the old Transcend (4G) and Hama (2G) cards failed after 5000 or so created files, but two brand new Transcend (4G) and SanDisk (16G) cards got well into the 70000ish range without any error before I finally stopped the test :)
Once again, thanks for all your input.

Good to know that SDFS itself seems to be OK :)

For what it’s worth, I haven’t had any problems at all. All of my major components (Pi, PSU, cards) are from RS so they should all be compatible (cards are Transcend, and the PSU has an RS sticker on it but appears to be from “HN Power”).

Could this have been related?

https://www.riscosopen.org/viewer/revisions/logs?ident=1414775301-309689.html

I understand that ROOL don’t want to step on the toes of Druck and his DiscKnight, but – really – name me an OS that doesn’t come with a basic file system recovery tool. I emphasise basic. DiscKnight does a lot of stuff. RISC OS really only needs to have *CheckMap do something better than say “map inconsistent with directory tree” and bail out, leaving you a damaged unusable file system. At the very least, it should validate both maps and offer to copy the one that matches the directory structure. Or, better yet, scan through the file system and attempt to rebuild the map. Anything other than be utterly useless. I’m not asking for a total fix it, leave the heavy lifting to DiscKnight. I’m just asking for a file system to be capable of recovering itself from a situation that appears to be more commonplace than in the past.

Can I second Rick’s statement, having just come across this issue myself.

*CheckMap’s documentation on the Wiki states:

If only one copy of the map is good, this command lets you rewrite the bad one with the information in the good one.

If bad map information cannot be cured, you should backup all of your files and then reformat your hard disc. Contact your supplier for more information.

Is this the case? It doesn’t look like it lets you rewrite the map to me, it appears to simply state that the map is inconsistent – which you already know as the OS told you to run it in the first place due to the map being inconsistent. Or am I missing an undocumented command line parameter?

I’ve not looked at the CheckMap source, but shouldn’t it verify the backup and either write it over the primary if its verified as consistent, or at least inform you that both are inconsistent. Perhaps it already does this, but the message it returns “Map inconsistent with directory tree” implies it just checked the primary map and is informing you its inconsistent. Should this message actually say “Both the primary and backup maps are inconsistent with the directory tree, please backup and restore your data”

In my scenario, RISCOS is bailing during the boot sequence when it tries to initialise Scrap and drops to a Supervisor prompt in a half booted state telling my to run CheckMap – can’t RISCOS in this situation either:

1. Prompt to run CheckMap (ie “Would you like to run CheckMap now Y/N?”)
2. Schedule CheckMap for the next boot

Are there any free utilities out there that I can use to fix the map?