Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 04/07/19 in all areas

  1. Because there is no documentation on how to support VSS on the file system level. There is documentation on how to access VSS, and plenty of it. But that's not the issue. The problem is how the file system is supposed to handle the VSS calls. There is NO documentation on this, in the wild. Any documentation that may exist is internal Microsoft documentation. If by Samba, you mean Samba/SMB/CIFS/Windows Shares, then you're just connecting to the API. You're relying on the underlying drive that the SMB share resides on supporting VSS. This is the top level VSS stuff, we need the bottom/low level info, how you'd implement it on a different file system. So, right now, we'd have to reverse engineer exactly how VSS interacts with NTFS, at the file system level. That is not a simple thing, at all. And it would be incredibly time consuming. If you mean a specific software, could you link it? Back up the underlying disks in the pool, not the pool drive. As for restoring .... basically the same. That or used something file based, or a sync utility (such as AllWays sync, good sync, free file sync, synctoy, etc).
    1 point
  2. I'm not sure? But the number of threads is set by our program. Mostly, it's just the number of open/active connections. Also, given how uploading is handled, the upload threshold may help prevent this from being an issue. But you can reduce the upload threads, if you want. Parallel connections. For stuff like prefetching, it makes a different. Or if you have a lot of random access on the drives... But otherwise, they do have the daily upload limit, and they will throttle for other reasons (eg, DOS/DDoS protection)
    1 point
  3. To my knowledge, Google does not throttle bandwidth at all, no. But they do have the upload limit of 750GB/day, which means that a large number of upload threads is relatively pointless if you're constantly uploading large amounts of data. It's pretty easy to hit 75mbps or so with only 2 or 3 upload threads, and anything more than that will exceed Google's upload limit anyway. If you *know* that you're uploading less than 750GB that day anyway, though, you could theoretically get several hundred mbps performance out of 10 threads. So it's sort of situational. Many of us do use servers with 1gbps synchronous pipes, in any case, so there is a performance benefit to more threads...at least in the short term. But, ultimately, I'm mostly just interested in understanding the technical details from Christopher so that I can experiment and tweak. I just feel like I have a fundamental misunderstanding of how the API limits work.
    1 point
×
×
  • Create New...