Activity for Bill McClain
-
Bill McClain modified a comment on discussion Help
Did you sync after the touch? The sub-second timestamp is an optimization feature to help identifying moved or copied files. Your files are protected even without it. From the manual: This improves the SnapRAID capability to recognize moved and copied files as it makes the time-stamp almost unique, removing possible duplicates. More specifically, if the sub-second time-stamp is not zero, a moved or copied file is identified as such if it matches the name, size and time-stamp. If instead the sub-second...
-
Did you sync after the touch? The sub-second timestamp is an optimization feature to help identifying moved or copied files. Your files are protected even with it. From the manual: This improves the SnapRAID capability to recognize moved and copied files as it makes the time-stamp almost unique, removing possible duplicates. More specifically, if the sub-second time-stamp is not zero, a moved or copied file is identified as such if it matches the name, size and time-stamp. If instead the sub-second...
-
You have 6TB of parity, not 6 + 4. The 6TB will protect any number of disks as long as they are 6TB and smaller. (Later you will add more parity disks for safety, as described in the FAQ). With 1 parity disk you can recover from the loss of 1 disk, data or parity. If you lose 2 disks at once you are in trouble. "if I create a system with 6+4+4tb of data (14tb) and 6 tb of parity, how much space I will have for data, considering only 6tb of parity?" You will have 14TB of data space. The parity disk(s)...
-
1 parity disc can protect any number of data disks, although as the number of discs grows you want more parity to protect against simultaneous disk failure. Number of parity disck = number of failed disks you can recover from. The FAQ has recommendations for the number of parity disks. It works because all the data disks cooperate when parity is calculated and all will cooperate if you need recovery. Articles on raid and parity will have details and diagrams. The parity disk(s) must as large or larger...
-
It's a recommendation, not a requirement. You are at risk of losing data if more than one disc fails at the same time.
-
I don't think 4 is possible. I would do 2, which I would call "simple". You'll be upgrading the 8TB someday and the larger parity will be ready for you.
-
As long as the largest amount of data on one of the 8tb drives does not excede 5tb, it would work.
-
That is how I understand it. If 3p fail you can recreate them from your data disks, but are unprotected against data disk failure until that completes.
-
Look at the values for: Reallocated_Sector_Ct Reallocated_Event_Count Current_Pending_Sector That suggests the disk is likely failing. I would replace it immediately.
-
Do "smartctl -a" on d4 to get the details on that disc. When was the last time you did a long test on it?
-
Snapraid is entirely file based, if that solves the concern. Your data files are left as they are, and parity and content are ordinary files and accessed as such.
-
No, you need two parity disks to recover from two simultaneous failures. The content files are identical on each disk; the duplication provides a bit of redundancy.
-
Sure.
-
I believe new disks must be added to the end. The config file says not to rearrange the order, which implies that new lines should be appended to the disk list.
-
There is no command, you just add a new line in the config file of form: disk DISK_NAME DISK_MOUNT_POINT From my setup, for example: disk d6 /mnt/tera06/ Snapraid will see the disk as part of the array thereafter.
-
I don't know about your identical files finding, but the FAQ has links to work-arounds: https://www.snapraid.it/faq#xls
-
Found my original report: https://sourceforge.net/p/snapraid/discussion/1677233/thread/30d2c4ea/#e1eb At the time "touch" was not working on unpartitioned discs.
-
I had some unpartitioned drives years ago and used them in snapraid. It worked but I had an operational issue which I'm sorry to say I cannot recall. Some missing functionality or reporting weirdness...? Partition tables are pretty small. I would use them.
-
Separate config files allows separate arrays: -c, --conf CONFIG Selects the configuration file to use. Does OMV have anyway to specify that?
-
I'm uncertain what causes that message. Was the file in fact modified since the previous sync? You don't have to delete it, just move it outside of the directory protected by snapraid, sync, then move it back and sync again. Be sure the file is in good condition, not corrupted.
-
Snapraid will need to make a parity file as big as your largest data volume. If you have only 1TB free on the 7TB device then there is not enough space. If you can move that 6TB elsewhere then it would work.
-
Yes.
-
There isn't any configuration as such. Each disk has top level directories known to snapraid.conf: music, video, audiobooks, backup, etc. Each also has a "delete" directory not known to snapraid and therefore unprotected. Moving deleted/updated files to "delete" is done manually, as is cleaning out that directory after sync.
-
Here is a common strategy for handling changes that I use. On each disk I keep a top-level "delete" directory. EDITED TO ADD: these are outside of the directories protected by snapraid. When deleting a file I actually move it into the "delete" directory temporarily. Same for modified files: move the previous version into "delete" before replacing it with the new version. After the next "snapraid sync": delete the contents of the "delete" directories. The reason: if I have a disaster between syncs...
-
Here is a common strategy for handling changes that I use. On each disk I keep a top-level "delete" directory. When deleting a file I actually move it into the "delete" directory temporarily. Same for modified files: move the previous version into "delete" before replacing it with the new version. After the next "snapraid sync": delete the contents of the "delete" directories. The reason: if I have a disaster between syncs I may need the old files to perform recovery. Snapraid isn't safe without...
-
It's working normally. Parity is as big as your largest data volume; it doesn't grow larger than that. Fill up your data volumes as is convenient. ...with the proviso that many small files can take up extra space in parity. The calculations are posted here from time to time. You should avoid filling a data volume 100% full. I archive my small files into one large file, which is easier on parity space. Also note that frequently updated files can cause recovery issues if you are updating them between...
-
Is one of the data drives nearly full? Parity will be about as large as the largest data volume. Having a zillion (approximately) small files also consumes more parity.
-
Reports are cropping up of a lot of packages having issues with a change in a default of gcc 10. Snapraid is one of them. Gentoo has a concise page on the problem: https://wiki.gentoo.org/wiki/Gcc_10_porting_notes/fno_common And it is the first topic on gnu's page: https://gcc.gnu.org/gcc-10/porting_to.html The fix is easy, but is best done in the source code.
-
It looks like a gcc 10 issue as discussed here: https://bbs.archlinux.org/viewtopic.php?id=255772 https://bbs.archlinux.org/viewtopic.php?id=255727 I updated and got the same results as you. The workaround for now is to add: CFLAGS="$CFLAGS -fcommon" to the PKGBUILD file. Delete the previous compilation results first. Adding the above to /etc/makepkg.conf didn't work, so this must be done to each package after downloading it.
-
snapraid is in the AUR. I just installed and tested it without error. Are you bulding from source, and is that needed?
-
It's been a long time since I first built the array. I remember syncing one disc at a time for the first half, then adding the rest all together. Total time seemed to be about the same.
-
It's a matter of managing your risk. If you need to recover only 1 failed disk you are ok. But if you have two failures at one time, you need two parity disks to recover. See the links to articles on failure rates in the FAQ: http://www.snapraid.it/faq#howmanypar -Bill
-
I've done it as you describe several times. The FAQ has this: http://www.snapraid.it/faq#repdatadisk I may have done a linux "cmp" between each file on the old and new disks, just to be sure. The FAQ suggests a "check" step.
-
Yes, your data discs can have as much data on them as you want. Snapraid doesn't control how you populate your discs, it just looks at what you have every time you run it. With "diff" you can see the differences since the last "sync".
-
tar.gz is the source package; installing it this way involves compiling the source, which is the standard method on linux when the distribution doesn't provide a pre-compiled version. You'll get a lot of errors trying this if you don't have development tools installed. Again, I don't know what is standard on Ubuntu.
-
There should be many more files than that, including INSTALL which gives the installation procedure. I use Arch instead of Ubuntu. Arch has a prepackaged snapraid in it's user-contributed repository (AUR) and installation is done by a standard procedure. Does Ubuntu have something similar?
-
Yes, move the A file to a pending-delete directory before putting the B file in it's place. Delete after the next sync. Same for to-be-deleted files. The names shouldn't be a problem. If you need the B file then you would have to move it elsewhere (or rename it) before moving the A file back into place for recovery.
-
Have you looked at the overview documents starting here? http://www.snapraid.it/
-
Managing changes and deletes: on each data disc create a "trash" directory that is outside of the array; that is: not protected by snapraid. When deleting a file from the array, don't really delete, just move it to the "trash". When updating an existing file, move the old version into trash first, then put the new file into place. Delete all the trash contents AFTER the next successful sync. This way you have the original files onhand should you need to do a recovery before the next sync. The fix...
-
Me too, but I do the same thing. Each disc has a "delete" folder outside of the array. I delete files by moving them there. After the next sync I delete them from that folder.
-
The library dependencies: ldd /usr/bin/snapraid linux-vdso.so.1 (0x00007ffff65fd000) libblkid.so.1 => /usr/lib/libblkid.so.1 (0x00007fea64bf3000) libm.so.6 => /usr/lib/libm.so.6 (0x00007fea648db000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fea646bb000) libc.so.6 => /usr/lib/libc.so.6 (0x00007fea64313000) libuuid.so.1 => /usr/lib/libuuid.so.1 (0x00007fea6410b000) /lib64/ld-linux-x86-64.so.2 (0x00007fea64e3b000)
-
The library dependencies: ldd /usr/bin/snapraid linux-vdso.so.1 (0x00007ffff65fd000) libblkid.so.1 => /usr/lib/libblkid.so.1 (0x00007fea64bf3000) libm.so.6 => /usr/lib/libm.so.6 (0x00007fea648db000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fea646bb000) libc.so.6 => /usr/lib/libc.so.6 (0x00007fea64313000) libuuid.so.1 => /usr/lib/libuuid.so.1 (0x00007fea6410b000) /lib64/ld-linux-x86-64.so.2 (0x00007fea64e3b000)
-
snapraid only runs when you execute it, so it is not going to object to ongoing system...
-
This may be obvious, but the 2TB restriction sounds like a limitation of the old...
-
My server currently runs openSuSE, just because that was my desktop system for many...
-
My server currently runs openSuSE, just because that was my desktop system for many...
-
My server currently runs openSuSE, just because that was my desktop system for many...
-
Your example shows 5TB of usable data space. I'm not seeing "the extra 1TB on the...
-
Yes, your parity disk(s) must be as large as your largest data disk, so you will...
-
The remaining drives cooperate in restoring the modified or failed drives. Any changes...
-
"Or i will be missing the files on D2 that were used with the old files on D1 for...
-
"Or i will be missing the files on D2 that were used with the old files on D1 for...
-
Your parity drive can have any number of files on it, one of which is a snapraid...
-
I'm on linux so I'll let someone else handle Windows disc questions. MBR partitioning...
-
(1) Yes. (2) You don't have to add more parity, in that 1 parity drive will work...
-
Something curious about "touch". I have three discs where touch is listing the files...
-
That's what I do. I direct the sync log to a temporary file, then use "grep -v verbose"...
-
Looking at my last log: I added 50GB, sync took 22 minutes. This is with 6 data discs,...
-
For what it's worth: the snapraid pool is just symbolic links to the physical files....
-
Log file behavior has changed in this respect: "verbose" messages were not previously...
-
I do that on Linux. No problems. -Bill
-
Googling around, I don't see any recommended best practices for running fsck. It's...
-
The parity by itself cannot rebuild lost data. Let's say you have 1 parity disk and...
-
No, this won't work. For recovery, all the good disks in the system are required....
-
Are you sure that was "sync" you ran and not "fix"? sync should have updated the...
-
Hello, everyone. I'm new here but have been following the forum for a while. I just...
1