no, I mean from the techsupport feature on the NAS 🙂
None of the volumes are mounted in tech support mode (including the os partition), so you can manually assemble raid and run btrfs check.
Though as I posted earlier, any btrfs repair is dangerous, so you need to back up the data before you do it. Also my view remains that you should proceed with a full reset anyway, as any btrfs repairs won't rule out an OS issue being the root cause of your crashes.
Note the btrfs errors you posted are duplicative - all the errors are in the same inode.
The original PSU fan is a 12V one. I've honestly never checked what voltage is applied to it, but it's constant -- no variation in speed due to temperature. But assuming it is running on 5V to keep it slower, another brand of fan rated the same at full voltage may run very differently at a lower voltage.
Yes I know, we've discussed that subject many times!
And you know my point of view as well! I just dislike the idea of having to reset the whole thing to fix a potential software issue, that's it.
Anyways, as this is not going to progress much further I suppose, I have hardware coming to transfer the file. Obviously now the NAS has stopped crashing.
Just out of curiosity, how do I assemble the RAID manually in techsupport? Also, I assume I can SSH in techsupport mode?
Also (!) is there a way to take a backup of the OS partition so it can be restored if something goes wrong?
Maybe the original fan had a higher airflow at lower speed then. Or maybe it's baking the PSU as well.
5V feels very low though. To make a 12V fan quieter, I'd expect it to be run around 8-9V. Anyways, no issues. I'll run it on 12V and the PSU will be fine.
Further to that previous message where someone said they did btrfs check but then decided to replace the affected file, how do I find out if there is a specific file which is corrupted following the check?
Further to that previous message where someone said they did btrfs check but then decided to replace the affected file, how do I find out if there is a specific file which is corrupted following the check?
You can use find /volume -inum xxxx, where volume is the NAS volume name and xxxx is the inode you are trying to resolve.
Having completed the backup, I logged into Techsupport. The btrfs errors were still there but find refused to accept the "inum" parameter. After much googling, I went nuclear and reset the whole thing.
It's syncing now.
Two thoughts.
1. The BIOS keeps showing HDD0 as "not found" every now and then. The OS never fails to detect it though
2. It took 20 hours to transfer my files over which the NAS NEVER EVER failed for a second. In fact, it's been online since I started the backup, no issues. If it disappears from the network it happens when it's idle, not when it's being used.
One question:
The OS defaulted to X-RAID, RAID5. I'm ok with RAID5, I believe X-RAID is what I want, right?
In other words, what should I change now that I reset the whole thing?
@StephenB can you remind me your recommended schedule for the drives - test, defrag ecc?
Is there a "recommended" steps somewhere to perform on a newly installed box?
Now please wish me luck because if this thing disappears again I promise I will make it disappear in a trash can 🙂
In other words, what should I change now that I reset the whole thing?
If you use snapshots, then I recommend using custom snapshots with limited retention (and not the "smart" snapshots). The "smart" ones have unlimited retention for the monthly snapshots, which eventually will fill the volume.
@StephenB can you remind me your recommended schedule for the drives - test, defrag ecc?
I run one test a month, cycling through all four 3 times a year. For example, my main NAS has
Disk Test: 1 Jan., 1 May, 1 Sept.
Balance: 1 Feb., 1 June, 1 Oct.
Scrub: 1 March, 1 July, 1 Nov.
Defrag: 1 April, 1 August, 1 Dec.
Disk Test and Scrub are deliberately placed 2 months apart. Since the Scrub accesses every sector on every disk, I feel it also acts as a good disk test.
If you don't think you need them, then I'd suggest disable them. I keep them enabled, because I have occasionally accidentally deleted a file in the share.
They shouldn't be enabled in some cases - for instance, if you have a live database or download torrents in a share. When files are repeatedly updated in place, the snapshots will create heavy fragmentation (because they operate at a block level).
I guess the snapshot can only be activated on the whole share, not on single folders?
Correct.
Note that BTRFS is storing deltas, so the on-disk space usage depends on how much you change (and how you change it).
The method is linked to BTRFS "copy on write". When the file system rewrites a block in a file, the original block is kept. The snapshot still uses the original blocks, the main share is using the updated one. Note that this means the file in the main share is fragmented.
However, many programs (for instance MS office) will just write out the entire file when you change it. So in that scenario, all the original blocks end up in the snapshot, and the file in the main share is only the new ones.
Anyway, I suggest custom snapshots. I limit them to 3 months retention, which keeps the total disk space used for snapshots pretty low. So you could start there, and then adjust retention on the share to keep the snapshot use reasonable (IMO less than 10% of the volume).
If you want to see snapshot use per share, you do need to enable volume quota from the volume settings wheel.
So if I modify a file outside of that schedule the change won't end up in a shapshop?
No, not exactly.
The snapshot captures the entire state of the share when it is taken. So files modified after a snapshot is taken will still show up in the next one.
But if you were to create a file and then accidentally delete it in between snapshots, then you wouldn't be able to get the original back - since the original file wouldn't have gotten into a snapshot yet.
If you set the schedule to take snapshots all the time (e.g., solid blue), then I suggest also using the option to only take snapshots if there have been changes in the share since the last one. That will reduce a lot of clutter.
Also, I don't set the "allow snapshot access" option, only the "allow access to windows previous versions". The reason is that snapshots are read-only if you don't set "allow snapshot access", but Netgear sets them to read-write if you do check it. Since IMO the purpose of the snapshots is to protect me from user error and perhaps malware, I don't want the snapshots to be writeable from Windows.
Say I set the snapshot ON at 2pm, the NAS will create a snapshop then.
What happens if I set the snapshot all the time (without selecting to only take snapshot when changes are made)? Does the NAS create a snapshot and when done it creates another one and so on?
How long does it take for the NAS to create a snapshot?
I think daily snapshots would work for me. Overnight is probably a good option. Do I check one of those blocks at - say - 2am to make that happen?
What happens if I set the snapshot all the time (without selecting to only take snapshot when changes are made)? Does the NAS create a snapshot and when done it creates another one and so on?
The custom snapshots are scheduled at most once an hour. So you'd get one every hour.
The thing you need to know about snapshots is that they don't copy the file content, so they are very fast and efficient. What they copy is essentially the directory entries and file allocations and they keep sectors of the drive that contain them from being re-allocated for the life of any snapshot using them (until those snapshots are deleted). So a snapshot of a share that has not changed doesn't really take up space. But it is one more snapshot added to the list when you go to restore. On shares with a lot of "churn", more snapshots will take up space much more than those without. Also, since defrag moves sectors around, it and snapshots together can also end up using more space, again especially on shares with a lot of "churn" (which are the ones that typically benefit the most from defrag). The snapshots will retain the old file layout, so defrag won't free any space but will take up new space.
I stumbled into some 4GB dimms and thinking of upgrading to 8GB. I know the Pro6 is fussy about that but these are 2RX8 modules and were mentioned on another thread as working fine. Attached.
