SFS errors out of the blue

[Piru]

What is the problem with iBrowse running on SFS partitions?

SFS is buggy. It corrupts itself on some actual usage (which browser cache generates).

I tried SFS couple of years ago. It'd commit suicide after single copy operation (it got as far as 20GB of data copied).

[Piru]

What would you recommend as an alternative?

PFS3 works for me.

However, some have had issues with PFS3, too.

Personally I know of single issue with PFS3: Delete large amount of data at once (say >4GB) and it throws up some warning requester and stops. However (for me at least) everything seems to be fine after reboot. If I delete the large amount of data in smaller chunks (say 2GB at a time) it works just fine.

PFS3 uses atomic commit. PFS3 includes pretty good repair tools.

Professional File System on wikipedia.

[Piru]

Well, I'd check the usual amiga dealers. The filesystems comes on a CD, with patch to latest version on aminet.

[Piru]

@ChrisH

SFS works 100% fine for me, including IBrowse. Anyone complaining about it probably was just unlucky and didn't have a backup. That or their HD is bad...

I'm afraid luck has nothing to do with it. SFS - while still being developed - still hasn't been able to iron out the fatal corruption bugs. It just gets even worse when SFS doesn't have proper repair tools. Once you've copied your data back and forth couple of times, each time being forced to reformat, I'd guess you might get a bit irritated.

Additionally SFS isn't very smart when allocating storage for the new data, and it gets worst case fragmentation when you write multiple files to the disk at the same time. That is just brain damaged.

I switch to SFS from PFS3, because PFS is *very* buggy with long file names

I've never had a single problem with long filenames, and I have lots of them.

I've used different PFS incarnations pretty much as long as they've existed (even back when they were free). I still have my files from that period. Just lucky?

[EDIT] That being said, considering the number of reports ppl having issues with PFS3, too, I can't just ignore them. Maybe I just am the luckiest man in the world? [/EDIT]

I would *not* switch back to PFS, because it is no-longer supported, where-as SFS is.

So what does this SFS support give you that PFS3 non-support doesn't? Does SFS have proper repair tool for example?

PFS3 still is the best filesystem for amiga and amiga compatible systems. PFS3 is far from perfect, but the alternatives are even worse.

[Piru]

@ChrisH

I'm sorry, but when most people *don't* have that problem, I tend to believe that it is the user's computer that is at fault.

So you'd recommend users to locate IBrowse cache on their SFS partition?

I am talking about names that are (say) 100+ characters long, although anything over 32 was risky. Any time I used excessively long files names, that file (if not the whole damn directory) became corrupt/unreadable (and once the entire partition was {bleep}ed).

You mean like these?

I have used AFS, PFS, PFS2 & PFS3

Same, although I used the early PFS too (before it was renamed to AFS).

[Piru]

@ChrisH

Weird, because the long file name corruption bug was 100% reproducible for me

Maybe your hardware was hosed?





Sorry, I couldn't resist ;-)

[Piru]

@LoadWB

Typically SFS seems to topple over when used a bit more heavily. Say, it isn't perhaps that typical to try to copy 100GB data to the partition at once.

[Piru]

@ChrisH

PFS is supposed to be "atomic commit", but it apparently has a design flaw which means it isn't unless you have a 1Kb () block size.

Atomic commit has been fine here, and I use blocksize of 512 everywhere. The only case I've managed to screw it up was by using cache app that cached disk writes at device level.

Even in that case pfsdoctor saved my butt.

[Piru]

Version numbers are not decimal numbers.

They're version dot revision [dot subrevision].

Each number should be considered separately. If previous number is the same, look at the next one.

See Wiki: Software versioning#Numeric

[Piru]

Commodore got it right twice: 2.04 and 2.05

Those were the "marketing" version numbers for the releases. Internally they were WB 37.67, KS 37.175 and WB 37.71/37.72, KS 37.299, 37.300, 37.350.

Probably the name with 0 was chosen so that release 2.1 would not appear "older" than the previous releases, though logically it should have been 2.10 then.

Ultimately this version sheme was set in stone by Commodore with the c:Version command. It interprets the numbers separately, rather than a decimal number. It's easy to test with couple of text files with $VER: tags.

[Piru]

@ChrisH

Did either you or Harry report this

This problem has been there for years.

And only SFS bombs like this. As soon as the cache is moved to FFS or PFS3, the problem goes away.

[Piru]

@ChrisH

All other things being equal, the simplest solution is the best.

SFS developers (whoever they might be these days) are well aware of SFS bombing pretty much frequently. So much, it's even considered a feature of the filesystem. There are procedures to "resolve" the filesystem corruption (copy data over, format, copy data back).

[Piru]

@ChrisH

Journaling filing systems are designed to handle unexpected hardware/software shutdowns/crashes in general (not cause them).

Journaling does not help against the filesystem corrupting itself. That's why it hardly ever helps to reboot after you get one of the infamous SFS error requesters...