So disParity is pretty awesome, and I had tried FlexRaid and SnapRAID before this and was considering shelling out for FlexRaid till I realised how simple disParity's GUI was. There is one feature I can't seem to find though, and that's scheduling updates etc. Obviously with the command line version you could use Windows scheduler, but im not sure how to do this with the GUI? Thanks for any help, and thanks for saving me money!
disParity » General Discussion
Schedule with GUI version?
(8 posts)-
Posted 2 years ago #
-
Hi Pete, thanks for asking about this. There's currently no way to schedule automatic updates in the UI. Another user asked about the same thing just a few days ago so it's clearly something the app needs. It's a feature that is very close to the top of my todo list and I'll be adding it as soon as the current beta is stabie.
Posted 2 years ago # -
Hey Roland, thanks for your reply! I just saw that post, and look forward to that being implemented! In regards to your post on the parity issue, is it generally safe to assume that as long as your parity drive is as big as your largest drive then the parity data should fit? Or are there any overheads that would make the parity data larger? Thanks again!
Posted 2 years ago # -
Yes there is some overhead on the parity drive, on average about 32K per file on your largest drive. So if your parity drive is the same size as your largest data drive, you can run out of space if you fill that data drive completely.
Posted 2 years ago # -
Oh okay then, so I assume the parity calculation for disparity is a different algorithm than the one used in a raid 5 array,as the general rule is that the parity drive has to be as large as the largest drive in the array? What causes these overheads vs a raid 5 array? This is all out of general interest of course :D
Posted 2 years ago # -
I actually don't really know the detailed specifics of how RAID 5 works under the hood.
The reason for the overhead in disParity is that disParity uses 64K blocks. Every file stored in parity has to start at a block boundary. But since files are rarely exact multiples of 64K in size, the end of the file only uses a partial block (e.g. a 100K file would use up 2 blocks, even though 2 blocks can store up to 128K, so the last 28K of the second block is wasted.) Since each file only uses a partial amount of its last 64K block, each file "wastes" on average 32K.
Also, even though the 32K-per-file overhead applies to all files on all drives, in terms of actual overhead wasted on the parity drive, only your largest data drive matters since everything else is overlapped in the parity data.
Personally, my parity drive is the same size as my largest data drive (3TB). I don't worry about any of this because I don't fill that 3TB data drive all the way up to the last byte.
Posted 2 years ago # -
Windows starts to complain when you get close to filling a drive anyway, and I always felt it is safest to keep some open space so the drive's self correction of bad areas has somewhere to move the data to - just a touch of paranoia on my part. Leaving 100MB free on a 3TB drive is insignificant - but it is a LOT of space for the "just in case" events. With drive prices being so cheap, it is better to be safe than sorry.
Posted 2 years ago # -
Oh, and add one more "me too" vote for a scheduler. Right now I just manually run the sync each time I add or delete files, but if I can just have it do it at midnight, for example, without me having to think about it I would be happier.
Posted 2 years ago #
Reply
You must log in to post.