SFS problem

[mechy]

Today I tried to install SFS with a modified WB 3.1 INSTALL disk. I discarded what was not needed and placed Smartfilesystem 1.279 in the "L" drawer and SFSformat in the root.

I more or less followed the tutorial as described in the wiki that explains how to use winuae to prep a HD with SFS for use in an A1200. Obviously I just skipped the winuae part.

I used a 60gb HD that I wanted to split in 2. I made one DH0: with 400Mb and  with the remaining space I made DH1:

DH0: shows up fine and I can format it with SFSformat after it shows up as DH0:ndos

But now the problem: DH1: show up fine in HDtoolbox ( but wrong partition size ) but it does not show up on my workbench as DH1:ndos and so I can not format it.

On DH0: I could install workbench without problems, and it boots fine.

So how do I get my second partition with all the diskspace ?

Sfs is a good filesystem, its much faster than FFS and supports long filenames,but it cannot fix the scsi.device which only supports 4gb partitions! you need to use nsd or td64 patches.

I have run SFS since it originally came out,and my system is still going fine(10 yrs?) as a matter of fact,its run on all the amigas i have.. Don't listen to the people above who don't set their stuff up correct and then complain its not reliable.You will need td64 and or nsd patch to be able to use all of the 60gb hd.
Its worth getting the full 1.277 archive that has the sfs docs. read them!

http://strohmayer.org/

Be sure to set the mask and max transfer on the crappy 1200 ide so you don't have problems(i assume you are using a A1200).values for these are suggested in the docs.you MUST do this.be sure to hit return where you type the mask and max transfer in or the values won't "stick".
As far as i know you should ALWAYS format sfs with the quick option. You can use workbench to format it just fine,you do not need to use sfs format.
you can use SFSCHECK in the 1.277 archive also to check the partition and make sure its ok after formatting.

Its amazing so much misinfo and problems still go on with sfs. RTFM people

[mechy]

People keep saying that all the time. But SysInfo reports the same speed for partions
formatted with FFS. For example:

I have an A1200/030/50Mhz 64MB - KickROMs 3.1 - WB 3.1 - 2GB HD.
Partition #1: 100MB, FFS filesystem.
Partition #2: 250MB, FFS filesystem.
Partition #3: 1650MB, SFS filesystem, (I've set the right mask and max transfer from
the SFS readme file)

SysInfo reports for all 3 partitions 2,5MB/s. So how does it come that SFS filesystem
isn't any faster?  :confused:
The same goes for my A1200 with 060 CPU.

SysMISinfo is useless for disk speed testing imho.

try something like diskspeed 4.2,which will actually flog the drives a bit under different situations. It may be if you are using old drives you are up against the limit they can move.
have you tried moving large files and timing it on both?
Also don't assume everyone uses a bog standard 1200 ide. I use a cyberstorm UWscsi as well as warp engine scsi and it shines there.A4000t(4091) etc.I have noticed a small speed increase as well as the buffered A4000 ide also.The 1200 unbuffered ide is probabaly the least place you would see a gain.

[mechy]

SFS is a nice file system with good features. But it's also very risky because there is not much support for it out there. It might run very stable over a long time, but *if* there is something wrong with an SFS partition, it's very difficult to get your data back, especially if you are not a programmer who wants to take the opporunity to develop a working salvage tool. There's SFSSalv and there's SFScheck, but there are enough threads in different forums which report these programs to not work correctly. In most cases, if something goes wrong with SFS, the only possibility to recover is to format the partition and to restore a backup.

So the conclusion is, if you choose to use SFS, make regular backups. Yes, this advice applies to every file system, but for SFS it is more important than for FFS. Firstly because there are many more salvage programs out there supporting FFS and secondly because FFS stores data in such a redundant manner that it's easy to recover files from a damaged partition.

The biggest mistake people make is that they confuse the lack of the need to validate with data safety. In fact data is more safe on an FFS partition than on an SFS partition.

Well i agree with the fact that sfs is a little harder to get the data back,but only a fool would not back his system up if its important.Theres really no excuse for not making backups,since its so easy these days(especially with a deneb usb or some such). Cf's and adapters are cheap, CD's,etc there are many ways. as long as you have a boot disk to get back in the worst of cases. i dont see how someone could confuse lack of validation with safety.Although i certainly don't miss validation on ffs.

[mechy]

Then there are a lot of fools out there (me included).



It does not validate, therefore it is more stable, therefore it is more safe. An easy conclusion most of the fools make (me excluded).


Also you don't make a backup every hour or so. A disk fault usually happens when you work with the computer and when you work with the computer, the data which is important changes a lot. In this situation nothing can be older than the backup from yesterday.

Well there is soft raid for amiga even hardware raids fail sometimes.We are all playing the odds
I dont use this myself,but may be a partial solution. In any case,life is never perfect

[mechy]

@mechy: best partial solution is a file system that doesnt get corrupted to soon, and that isnt sfs in my book. i have to evaluate pfs, but the original ffs was trusty too in its time, validation aside.

as for sfs since there are so many variants, original, strohmayers 68k and os4, mos etc its quite difficult to determine which fails and which not. misunderstandings are certain.

well,all i can say is i have been using it many years,and i've never had a fail or had to recover.
i am running strohmayers 2.79 on a A4000,csppc,2-32GB cf's on the uwscsi with adapters,mediator etc. I use this system daily and it runs 24/7,i don't just play games,and this poor machine gets to be the test bed for all my zorro cards  and hard drives usually.
Its also on 2 of my 4000t's(4091 scsi),2-A3000t's,3-1200's(one 060,one 030,one stock) and the viper520cd in the A500.None have given me any troubles. It could very well be that some are trying to use a old buggy versions. There were a few buggy ones in there i guess.My A500 is using 1.84 on the viper520cd fine.From what i can tell,about 80% of the time its a case of people haven't set it up right,or read the docs,or bad cables,cheap cf cards that don't impliment ide right(there's tons of knockoffs out there).i have helped alot of people install it over the years and its worked every time.its almost always been a config error in hd tools or a issue with td64/nsd..a few have been cable troubles and bad ram(this effects everything!). who knows?

[mechy]

@mechy: this is what your personal experience is, while mine is different. they are both of equal value. whereever i discussed the matter with people that claimed sfs to be perfect, they mostly turned out to be mos users, as if it was selfexplanatory. thats why i ask.

now, a test case proves something till it fails. in your case it havnt yet, in my - multiple times. take into account it is not enough to use your system 24/7, and stick different expansions into it to prove this point. my rack remains pretty unchanged all the time. writing and reading the drives a lot may trigger the bug more likely. note that i dont want to opress anybody not to use sfs, just to warn to use a filesystem that seems more secure atm.

well i would think setting it up on 40+ assorted amigas over a 15+ year time frame is a pretty good test.No one said sfs was perfect.

[mechy]

same as me at least, but in fact you must refer to other filesystems. strohmayers sfs is not that old. so it broke on me sooner. with the original ive had no intercourse.

yea i started with earlier versions and moved up over the years.