271–280 of 314 posts
Can someone explain why a single geolocated node makes sense for data storage? If there's a house fire for example, wouldn't all the data be lost?
My NAS is basically constantly in use, between video footage being dumped and then pulled for editing, uploading and editing photos, keeping my devices in sync, media streaming in the evening, and backups from my other devices at night..
Earlier quoted context omitted.
> Data integrity is the natural expectation humans have from computers I've said it once, and I'll say it again: the only reason ZFS isn't the norm is because we all once lived through a primordial era when it didn't exist. No serious person designing a filesystem today would say it's okay to misplace your data. Not long ago, on this forum, someone told me that ZFS is only good because it had no competitors in its sp…
The reason ZFS isn't the norm is because it historically was difficult to set up. Outside of NAS solutions, it's only since Ubuntu 20.04 it has been supported out of the box on any high profile customer facing OS. The reliability of the early versions was also questionable, with high zsys cpu usage and some times arcane commands needed to rebuild pools. Anecdotally, I've had to support lots of friends with zfs issues…
Has this changed ? ZFS comes with a BSD view of the world (i.e slices). It also needed a sick amount of RAM to function properly.
Can someone explain why a single geolocated node makes sense for data storage? If there's a house fire for example, wouldn't all the data be lost?
I’m guessing that the 71 TiB is mostly used for media, as in, plex/jellyfin media, which is sad to loose but not unrecoverable. How would one ever store that much of personal data? I hope they have an off site backup for the all important unrecoverable data like family photos and whatnot.
Earlier quoted context omitted.
I tried it out on my homelab server right after the merge into the Linux kernel. Took roughly one week for the whole raid to stop mounting because of the journal (8hdd, 2 ssd write cache, 2 nvme read cache). The author responded on Reddit within a day, I tried his fix, (which meant compiling the Linux kernel and booting from that), but his fix didn't resolve the issue. He sadly didn't respond after that, so I wiped a…
New filesystems seems to have a chicken and egg problem really. It's not like switching from Nvidia's proprietary drivers to nouveau and then back if it turns out they don't work that well. Switching filesystems, especially in larger raid setups where you desperately need more testing and real world usage feedback, is pretty involved, and even if you have everything backed up it's pretty time consuming restoring ever…
Crypto implementations and FS implementations strike me as the ideal audience for actually investing the mental energy in the healthy ecosystem we have of modeling and correctness verification systems
Now, I readily admit that I could be talking out of my ass, given that I've not tried to use those verification systems in anger, as I am not in the crypto (or FS) authoring space but AWS uses formal verification for their ... fork? ... of BoringSSL et al https://github.com/awslabs/aws-lc-verification#aws-libcrypto...
the 'secret' is not that you turn them off. it's simply luck. I have 4TB HGST drives running 24/7 for over a decade. ok, not 24 but 8, and also 0 failures. But I'm also lucky, like you. Some of the people I know have several RMAs with the same drives so there's that. My main question is: What is it that takes 71TB but can be turned off most of the time? Is this the server you store backups?
> What is it that takes 71TB but can be turned off most of the time? Still waiting for somebody to explain this to me as well.
Earlier quoted context omitted.
I only know about FAT but these "key file metadata blocks" are redundant, so you need really special double-plus bad luck to do that.
so I can consider myself very lucky and unlucky at the same time. I had data corruption on zfs filesystem that destroyed whole pool to unrecoverable state (zfs was segfaulting while trying to import, all recovery zfs features where crashing zfs module and required reboot) the lucky part is that this happened just after (something like next day) I migrated whole pool to another (bigger) server/pool so that system was…
I run a similar but less sophisticated setup. About 18 TiB now, and I run it 16 hours a day. I let it sleep 8 hours per night so that it's well rested in the morning. I just do this on a cron because I'm not clever enough to SSH into a turned off (and unplugged!) machine. 4 drives: 42k hours (4.7 years), 27k hours (3 years), 15k hours (1.6 years), and the last drive I don't know because apparently it isn't SMART. 0 e…
Looks like you're quite clever actually, if you can get cron to run on a powered off unplugged machine. I think I'm missing something.
0 2 * * * /usr/sbin/rtcwake -m off -s 28800 # off from 2am to 10am
"and unplugged" was referring to OP's setup, not mine
There have been drives where power cycling was hazardous. So, whilst I agree to the model, it shouldn't be assumed this is always good, all the time, for all people. Some SSD need to be powered periodically. The duty cycle for a NAS probably meets that burden. Probably good, definitely cheaper power costs. Those extra grease on the axle drives were a blip in time. I wonder if backblaze do a drive on-off lifetime stat…
They used internal 3.5" hard drives along with USB docks to backup a couple Synology devices...It seemed like 1/10 times when you put a drive back in the dock to restore a file or make another backup, the drive wouldn't power back up.