Jump to content

fattipants2016

Members
  • Posts

    80
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by fattipants2016

  1. I see you can configure the delayed write option to store the data 'indefinitely' in level 2 cache, but I don't see anywhere that you can schedule how often it flushes to disk. If I could store all of my file changes in level 2 cache, and flush them to disk on a schedule once a night, it would be a perfect replacement for the way I'm using the SSD optimizer. I'm trying to mitigate changes to my archival drives between updates of my SnapRAID parity data, but if primocache had this scheduling feature it'd be even better.
  2. If you use file placement rules to make one or more folders exist only on the "SSD" drive, they'll never be moved off since they have nowhere to go. They'll continuously contribute towards your balancing quota, however, because DrivePool wants the SSD to be empty when it's done balancing. I used to do this, but life is better now that I created a 2nd partition for these 'temp' files to be moved to.
  3. do you have the 'unless the drive is being emptied' rule turned on, by any chance?
  4. I don't know if it will be worth $30 in my use-case (archival data) but I'll definitely give it a whirl and see if it knocks my socks off. Do you recommend caching the physical disks, or the pool?
  5. That's actually a great solution. Would DP be clever enough to handle the process being stopped during a write or something? It's definitely not worth breaking anything. Yeah, it really only comes up because I have a lot of folder placement rules which make my drives unevenly balanced. Almost wasn't even worth mentioning, but I figured i may have overlooked an option to ignore it.
  6. Each physical disk has a recycle bin outside the pool. The pool has it's own, inside the drivepool data folder. That's the one I'm fairly certain Drivepool spends time balancing.
  7. There might be another way, but I used file placement rules, and unchecked the disk I wanted to remove from every folder. Worked great.
  8. Will primocache store file/folder directory tree information so that every darn disk in my computer won't spin up when I open Windows Explorer? I'd say DrivePool's own SSD optimiser is an effective alternative for this software already, but I would kill for ^^ this functionality.
  9. I do exactly this. Be sure to check the 'leave the files where they are' option in the SSD optimiser and it will leave the files on your achive disks alone. There's no FIFO, though, you'll need to schedule or define triggers for balancing, at which point Drivepool will empty your SSD's onto your archive disks.
  10. Looking for a hack to make this work, otherwise I hope this could be added some day. I'd like a way to balance less frequently than 24 hours (once a week would be ideal,) but still at a scheduled time (1:00AM) to coincide with my SnapRAID sync schedule. BTW, not worth an extra post, but does DrivePool balance the recycle bin!? Is there a way to make it ignore it? There might be 100's of GB in my recycle bin at any one time.
  11. Turn off 'unless the drive is being emptied.' I experimented with that option and had the same problem.
  12. The previous issue was to do with the SSD optimiser migrating files to the SSD during balancing, rather than from one Archive disk to another. Same issue xazz reports in their thread 'DP constantly fills and then empties my SSD' Now my file placement rules, which had been working for months, stopped working with either the Windows or DP update. There are multiple folders in the pool. There's a temporary folder, which gets sorted into folders A, B and C based on content. Folders A, B and C have their own disks. The desired (previously working) behavior is for A, B and C to be balanced only to their assigned disks, and if their assigned disk is >90% full, resume standard (least filled) balancin to the other disks. Folder B has overflown it's assigned disk (months ago), and DP had been correctly sidestepping the placement rule, and balancing the excess files. Now the "allow files to be placed on other disks.." rule no longer works. I've sidestepped the issue by assigning a second disk to the folder, and using the SSD optimiser's 'ordered placement' function, but I'm effectly having to manually dictate file placement where I didn't have to before.
  13. Is this File Placement option broken in 2.2.1.926? I upgraded after updating windows to the 5-18 and now DP refuses to balance, (7.28TB could not be moved because a suitable destination could not be found.) I've wiped my settings, and reconfigured them one at a time. My configuration is identical to my still unresolved post, here. **Before I'm asked, I'm using this option to designate a specific drive to a particular folder, and once the drive is ~ 95% full, allow it to 'spill over' onto other drives. If I actually select the other drives in file placement options, DP will start pulling files OFF of the designated HDD, which isn't what I want.
  14. SnapRAID will attempt to fill in the gaps with new files, the parity file only grows by the random unfilled space left over. It's trivial per-file, but creating parity data from scratch takes me a full day so I'm just trying to be mindful. If you ever do run out of space for parity data, you can have it span to another disk, or have SR generate a report about which files are creating the most overhead. I'm mostly being anal retentive about a lot of this stuff up front, so I can (before long, I hope) forget about it, and let it do it's thing.
  15. They may not be monitoring this thread anymore, since I marked it answered. Does the folder D:\stablebit drivepool\service\ already exist? Is it write protected? Try putting the file in the root of D:\ just to rule out any problems with the path. Another thing to try is to temporarily re-instate the "DrivePool.Service.exe.default.config" (rename to DrivePool.Service.exe.config) settings file in programfiles, and enable it there. I got it to work that way, temporarily, until I heard about having to use the double \\'s. Just don't forget to rename (disable) those old settings, afterwards.
  16. Well... I found a stop-gap solution in simply making my landing zone & scratch disk one in the same. This way files only ever move in one direction. This means I cannot take advantage of my SSD, though, and all files must migrate through my relatively slow 2.5" mechanical scratch disk. If this is a bug that gets fixed in the future, or there truly is something wrong with my settings, I'd really love it if someone let me know.
  17. There's actually several compounding issues. - My mechanical hard drives are all in a shared external enclosure which lacks individual-drive power control. I'd like to prevent spinning it up as much as possible. - Any time a file is removed / changed / added to SnapRAID, data of equal size to the changes is vulnerable on each of the member disks. I'd like updates to happen on a schedule. - Unlike a true RAID-5 which uses sector-by-sector (file system level) parity data, SnapRAID's file-level parity data actually grows in size when files are changed or replaced. You could potentially end up with a parity (back-up) drive that's completely full, and large chunks of empty unusable space on your data disks. The SSD addresses issue #1 by accepting new files throughout the day without spinning up the enclosure. The scratch disk holds files older than a day, until I've decided whether or not they're truly worth committing to the archive, which solves #3. Together they solve #2, but they're both equally important and serve different problems.
  18. Thank you! That worked. Is there any plan to, or a layman explanation why not, add support for event logging? It would have been very easy to trigger snapraid based on an event. And for anyone else with similar needs, I used a powershell script called "Powershell FileSystemWatcher" to write an event, and used said event to trigger snapraid-helper (also PS.) A bit convoluted, but launching one powershell script from another is suprisingly complex.
  19. DrivePool_RunningFile doesn't seem to do anything in 2.2.906. I've tried both "Override: C:\Snapraid\Balancing.txt" and "Override: "C:\Snapraid\Balancing.txt"" (with and without quotes,) rebooting before each test. No file is created at any point during balancing. I still desperately need help with my SSD Optimizer balancing issues, as well.
  20. Thank you. I should be able to do something with that.
  21. Easy question, today. Is there any way to trigger a scheduled task, or execute a script from the command-line after balancing? I'm trying to sync DP & SnapRAID, and by time isn't cutting it. I disabled DP's background balancing, and told the scheduled task (SR) to only start when the computer's idle, but it just starts in the middle of balancing anyways.
  22. And to make sure we're on the same page, a much more succinct explanation of the problem (with the visual aids above) goes like this: 1.) New files are copied to drive "Y", but they're captured by drive "C" (the SSD)' = GOOD 2.) On the next balancing pass, they're moved to their original destination, drive "Y" = GOOD 3.) Same file is moved to a folder on drive "X", but remain on drive "Y" until balancing occurs = GOOD 4.) On the next balancing pass, the files are moved back to drive "C" (the SSD) and stay there = BAD 5.) On the next balancing pass, the files are finally moved from drive "C" to their intended destination, "X" = INDIFFERENT
  23. So while I'm waiting to hear back, I tried a bunch of configuration combinations to try and resolve the issue. - disabling "file placement rules respect real-time..." makes new files skip the SSD entirely - disabling "balancing plug-ins respect file placement rules" makes files go everywhere (expected) - no combination of these options forces the SSD to ever be used if it's removed from all placement rules I've also found out that if more data is moved between archive drives than my SSD can hold (250GB) the entire balancing pass gives up, and throws the (paraphrasing) "xxxGB could not be moved ... no suitable destination could be found." If this is a problem with my settings (pictures above) please let me know!
  24. Sorry about that, I got side-tracked from being side-tracked by this for a few days. I verified that this issue is in fact still happening. I moved ~3GB of files from folders on "V:\" to folders on "W:\" and they were in fact moved to "C:\" instead. Only forcing a second balancing pass finally moved the files from "C:\" to "W:\" And yes, I realize incorporating "C:\" isn't best practices
  25. I'm not sure if this belongs in General or Nuts and Bolts but here goes. Basic scenario is I have 4 "drives." 1.) Operating system SSD (not part of the pool.) 2.) SSD landing zone (SSD-optimizer places all new files here for speed.) 3.) HDD 'scratch disk' (folder placement rules place my "temp folder here" when the SSD is emptied in order to hide it from SnapRAID) 4.) Archival drives (folder placement rules migrate my "archival" folders here from either the SSD or scratch disk. This is what SnapRAID sees.) The issue I'm having is that when balancing occurs, files / folders that are being moved from #3 to #4 are being copied BACK to the #2 first. This creates two issues. 1.) #3 and #4 are equally slow, so copying the files to #2 first means balancing takes twice as long as if they were copied from #3 to #4 directly. 2.) The volume of files being moved from #3 to #4 often exceeds the capacity of #2, so balancing has to be run multiple times for everything to migrate successfully. I'm not sure if there's something amiss with my placement / balancing rules, this is the intended behavior, or if this is just a scenario that's never come up. - I have 'file placement rules respect real-time file placement limits' unchecked. - I have 'balancing plug-ins respect file placement rules' checked. - I have 'unless drive being emptied' unchecked. Let me know if I need to clarify anything, I've been playing with it for so long I'm having trouble thinking straight. Thanks in advance.
×
×
  • Create New...