New Shell process 6 6.Workbench:> "RAM Disk:Smartfilesystem/SFScheck" hd0: Partition start offset : 0x00000000:0011ee00 End offset : 0x00000021:69a0d400 Surfaces : 17 Blocks/Track : 15 Bytes/Block : 512 Sectors/Block : 1 Total blocks : 280282995 Device interface : NSD (64-bit)
Checking RootBlocks Checksum failure. ...damaged 6.Workbench:> "RAM Disk:Smartfilesystem/SFSconfig" hd0: SFSconfig information for hd0: (SFS version 1.293) Start/end-offset: 0x00000000:0011EE00 - 0x00000021:69A0D400 bytes Device API: NSD (64-bit) Drive data: 512 bytes/block, 280282995 total blocks Read-ahead cache: 4 lines * 1024 bytes readahead size = 4096 bytes 440791 accesses, 1923 (0%) misses Copyback mode enabled Max Name Length: 107 DOS buffers: 600 SFS settings: [NOT CASE-SENSITIVE] [RECYCLED, 350 entries] 6.Workbench:>
Whats the problem i just created these partitions on the 8th of this month. I hardly used the Computer. Drive is swapped out i disconnected the SSD for a Spinning drive to see if it is the same.
Whats the problem i just created these partitions on the 8th of this month. I hardly used the Computer. Drive is swapped out i disconnected the SSD for a Spinning drive to see if it is the same.
SFS doesn't support SSDs (using ATA Trim would be required), nor does any of the other old AmigaOS file systems. No idea about NGFS.
Using current HDs is a problem with SFS as well, make sure you only use very old HDs (512 bytes/sector) with SFS. 4k sector HDs aren't supported by SFS, and the internal 512 bytes/sector emulation of such drives can't work reliable either. Using another file system like FFS instead should work on 4k sector HDs, but only with manually tweaking the partition start sector numbers in MediaToolBox and using a block size of 4k, or a multiple of it, it can work reliable.
Adding support for 4k sector HDs and SSDs in SFS itself would be quite easy, but it could only be done after MediaToolBox and the ATA drivers are updated to support such drives, which will probably never happen.
I am using an SSD on my X5000 with SFS formatted partitions, not too many problems. I did have one partition become unwriteable, had to backup, reformat and copy back to it no problems.
I think Trixie is using the beta version of NGFS, which I understand is pretty good. However, I'm using the version that shipped with my X5000 and it's very buggy. Have lost a number of NGFS partitions.
That doesn't really leave me with many options, except FFS.
Hmmm. I am sure I am using an SSD with SFS partitions in one of my X1000s. Am I asking for trouble?
Yes. Compared to HDs the flash memory used in SSDs has a very limited amount of write cycles until a sector is dead. Using an old file system like SFS or FFS, for example both overwrite the very same sector twice on each change, does work, but it will kill the drive very much faster than using a file system with SSD support does.
Quote:
Not sure about my HD sectors
AFAIK you can't even check the HD sector size on AmigaOS, the ATA drivers always returned 512 bytes/sector even if it's a 4k sector HD. 4k sector HDs support writing 512 bytes (read 4k, modify 512 bytes, write back), but that's not only slower, if SFS doesn't know the real sector size it's "safe writing" can't work. Using FFS is better on such HDs, it's internal disk validator can fix errors most of the time. Even if not there are tools to repair broken FFS partition, with SFS partitions you have to restore a backup instead.
In my Amigas I am using SSDs with self-trim features. I hope that helps. What is your opinion on that?
Auto trim/garbage collection can't help as much as using file systems which use ATA TRIM.
Some % of the internal total space on the SSD are reserved sectors, not included in the reported SSD size, not accessible from outside and only used for replacing bad sectors. HDs have reserved sectors for that as well, but much less % since the sectors don't get bad as fast as on SSDs, can be checked with SMART tools.
Theoretical way SSDs can extend their life time with ATA TRIM, if the SSD firmware really does implement something like that is something completely different, at least early SSDs often had a lot of firmware bugs. a) Using file systems without ATA TRIM: - If a sector gets bad it's replaced by one of those reserved sectors. That's automatically done on writes. - If there are none of the initial reserved sectors left the SSD is dead. b) Using file systems with ATA TRIM: - File system uses ATA TRIM on unused sectors, for example when quick formatting a partition or deleting files. - SSD firmware moves or replaces those unused sectors to/in it's reserved sector list, sorting them by the write counts, i.e. the next sectors used for writes and replacing bad sectors are the ones which have been overwritten the least. - SSD firmware has much more and better (overwritten less) sectors to replace bad ones and the SSD will last much longer.
There isn't much you can tweak, but a few things can help when using old file systems on a SSD:
Increase the forced write timers (activity and inactivity flush timeout, supported by at least SFS and FFS2) to the maximum supported by the file system.
When using SFS remove diskcache.library from your kicklayout, it writes much more than required. If one of it's cache lines has to be written back to the disk and it's for example something like "uumuuuumuuuuumuu" of (un)modified sectors it's using a single write of 12 sectors from the 1st to the last modified sector instead of just writing the 3 modified sectors to the disk. Even if more data has to be transferred a singe write of 12 sectors is much faster than 3 separate writes of one sector each, but for SSDs that optimization is bad.
Should be obvious, but don't defragment partitions on a SSD.
It probably would if it could use it, but that's unlikely. SG2's ATA drivers did support using ATA commands, but IIRC using internal, undocumented features were required for that, used by for example by his smartctl tool. AFAIK the HD_SCSICMD emulation only supports sending ATA commands to optical drives (MMC standard), but not sending other ATA command to HDs/SSDs. P5020stata.device, and maybe the X1000 and SAM460 ATA drivers as well, aren't even based on SG2's (S)ATA drives (A1 SE/XE, sii0680, sii3112, sii3114, SAM440ep, etc.) but using a different, incompatible code base which makes it even more unlikely that they support ATA commands.
I used SSDs with SFS on my computers very long time. On AmigaOS and MorphOS, SFS and SFS2, prepared both with MorphOS and AmigaOS tools. SSDs are SATAIII (most of them Kingston) connected to SATAII (X1000) or SATAI (all others) controllers. Blocksize I have 512, only on X1000 both 512 and 4096
All working perfect many years, on AmigaOS with S.M.A.R.T, on MorphOS without (due to his sata.device)
Even on X1000 there are no speed or other differences between 512 and 4096 blocks. All machines was heavily benchmarked.
So, my result is: don't be afraid of SSDs with SFS! Regardless of theory, practice says it's OK.
controllers: X1000 builtin southbridge AMD SB600 G5 Quad builtin type? is OK, PCIe SATA SiI3132 not works for me (also under linux) Pegasos 2 PCI SiI 3114 (tested also with Promise SATA II and all SiI 3xxx) Micro A1-C PCI SiI 3512 Sam440ep-flex builtin SiI 3114 Pegasos 1 PCI SiI 3512
only use SSD’s in my 68k miggies but in my X1000 I’ve been using SFS/02 since day 1 release every day with no issues at all with SATA ‘real’ moving parts HD