Not all of them. Some 30 pin SIMMs had parity, which is not the same as ECC. ECC on SIMMs was only on some of the 72 pin SIMMs, at a much later date.I think at that time all RAM modules (SIMM) had ECC.
Not all of them. Some 30 pin SIMMs had parity, which is not the same as ECC. ECC on SIMMs was only on some of the 72 pin SIMMs, at a much later date.I think at that time all RAM modules (SIMM) had ECC.
So do other file systems. Normally, file systems fill all memory with disk cache. ZFS's caching is not particularly aggressive, nor does it keep unwritten data (write cache) in menory particularly long.Well, there is some logic in it: ZFS keeps a huge amount of filesystem data in memory for long times,
I don't know. I should read the slides from the talk that Kirk McKusick gave a few days ago about how ZFS is implemented on FreeBSD. I think that all data and metadata in the memory cache is checksumed.and AFAIK it is not checksummed while being there.
Yes. But one of the design principles of ZFS is that it never overwrites anything on disk. So if a metadata block is written damaged, the old copy of it is still on disk too, which makes the problem restorable and fixable for a long time (until the old data needs to be overwritten due to space concerns). I don't know how hard it is to fix such a problem though.Then, if it happens that this bitflip indeed concerns the toplevel master node (or whatever the thing is called) of a pool, then data might be written out damaged in a way that the pool structure becomes unintellegible.
Fsck can repair some errors, but not all. A completely shredded metadata block (like inode or directory content) if often not repairable.This is different to other filesystems. There fsck could repair such errors.
Traditional file systems also have metadata (superblocks, inodes, directories, indirect blocks), and they also cache those in memory.And the bitflip would rather hit cached application data, so then the application data might be silently wrong, which might be just as bad.
I agree, using ECC is good, but not any all cost. You are still better off with ZFS on non-ECC than with a other file systems on non-ECC.Nevertheless, I do use ECC where I can, and I recommend it for 24/7 operation.
As others have commented here that's entirely subjective if you have an option of to ECC or not ECC. However, I'd rather pay the extra for ECC memory if it's within my budget for my servers running ZFS than not for an additional level of data integrity. Plus some servers only support ECC memory such as my Lenovo TS430. If ECC wasn't that big of a deal then why do many servers require it at a hardware level?Anything the FreeNAS forum has to say on ECC is complete bullshit. (It's the birthplace of non-ECC-mem-will-break-your-entire-ZFS-pool FUD.)
This is a FreeBSD forum; not Lummux. Since you're here on your high penguin, you should be ban hammered.I don't care what you personally use. Just please stop scaring hobbyists into choosing ext4-based Linux NAS solutions. This is completely counterproductive.
I don't even know WTF you're talking about because I don't use Lummux. Speak BSD or fasthalt.Just please stop scaring hobbyists into choosing ext4-based Linux NAS solutions. This is completely counterproductive.
Already done. I also commented in the feedback forum because I've seen people who don't follow the rules posting here that should be gone. If they need an enforcer for it, I'm volunteering.Oh my… You are welcome to report me.
If they need an enforcer for it, I'm volunteering.
If you have to make a tradeoff between ECC and an extra disk or better disk, the extra disk MIGHT be a better investment. It depends on how much disk redundancy you already have. But I agree, the extra cost of ECC DIMMs (if you already have an ECC-capable motherboard) is not very high, so in general it is a good idea.To me it seems simple if you have an option to go with ECC choose ECC, ECC is always better.
Someone called? Splendid!You'll ban 3/4 of the forum members It's not a coincidence that the moderators are the most chill people here.
If you have to make a tradeoff between ECC and an extra disk or better disk, the extra disk MIGHT be a better investment. It depends on how much disk redundancy you already have. But I agree, the extra cost of ECC DIMMs (if you already have an ECC-capable motherboard) is not very high, so in general it is a good idea.
If you are running ZFS, the best investment is to buy a sufficiently large number of disks to use a sufficient RAID code (the more fault tolerant, like Z2 or Z3, the better). The second best investment is to buy high-quality disks (enterprise grade). The third best investment is to buy or rent hardware for remote backups, to protect against destruction of the primary server (either by hardware or operator error). Perhaps the priority of "second" and "third" could be switched. And ECC is next.
my FreeBSD box handles low memory VERY poorly with slowing down like swap is in use to use the filesystem even when swap is disabled and other nondisk slowdowns with long pauses and system freezes when I would expect the system to say, 'RAM too low; closing a program' but it just wont.
I would expect the system to say, 'RAM too low; closing a program' but it just wont.
And the system has no means to "close a program". The only thing it can do is kill a process, violently und unexpected. And that is the worst thing that can happen. It is better to create a system panic and reboot and do the things from start again.
For what it's worth, I'm perfectly fine with Firefox being killed on OOM. It's practically impossible to estimate RAM requirements for that thing anyway and the alternative is a complete lockup.
Meh. This is no different from a crash on segfault. Programs definitely should be written to handle restarts.
$ /usr/local/sbin/pkg info | grep firefox
firefox-esr-68.4.2,1
$ ps axlw | grep firefox
1100 1245 1204 0 21 0 3531752 832108 select Ss - 407:23.97 firefox
1100 1247 1245 0 20 0 3273584 699068 select S - 462:20.97 /usr/local/lib/firefox/firefox -contentproc -childID 1 -is
1100 1248 1245 0 82 0 3457580 837980 - R - 1030:30.98 /usr/local/lib/firefox/firefox -contentproc -childID 2 -is
1100 1249 1245 0 20 0 2462732 66572 select S - 1:50.30 /usr/local/lib/firefox/firefox -contentproc -childID 3 -is
$ top -b
last pid: 38885; load averages: 0.99, 1.11, 1.07 up 6+19:28:48 20:48:01
116 processes: 2 running, 114 sleeping
Mem: 788M Active, 1284M Inact, 381M Laundry, 5066M Wired, 775M Buf, 326M Free
ARC: 2389M Total, 1727M MFU, 262M MRU, 1666K Anon, 63M Header, 336M Other
1568M Compressed, 3436M Uncompressed, 2.19:1 Ratio
Swap: 10G Total, 1733M Used, 8507M Free, 16% Inuse
Anyone who knows aboutFor me, it is ECC where ever possible. Even my new laptop will come with ECC memory, I would never consider building/buying/using a server without it. Also a good argument for Ryzen CPUs, which mostly support ECC (I believe only Ryzen 3 does not).