Jump to content
Covecube Inc.


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Alex

  1. That's odd, it was in the logs that I saw. Yes, absolutely. A CRC error should show up in the SMART data instantly and a surface scan will pick it up as well. We store the volume name in an alternate data stream on the pool's root directory. So it's likely that the issue has something to do with that. Can you capture a file trace log of the rename operation like this: Under Settings -> Troubleshooting enable File system logging. Perform the rename operation that results in the error. Then uncheck File system logging. This will capture a file system log of the error that I can look at to get a better idea of where the error is coming from. The trace files will be saved to: C:\ProgramData\StableBit DrivePool\Service\Logs\CoveFs Just ZIP those up and upload them here: http://wiki.covecube.com/StableBit_DrivePool_2.x_Log_Collection Let me know once you have that uploaded and I'll take a look. Thanks,
  2. You must mean StableBit DrivePool 1.X, no these features will not be added to 1.X however 2.X does run on WHS 2011. I am still actively making fixes to 1.X as you can see here: http://dl.covecube.com/DrivePool/beta/download/Changes.txt But adding major features to both versions is just not practical.
  3. The main reason why we're stuck at 432 is because I was trying to fix all of the important bugs that were reported as of the last release. We have a brand new system for keeping track of reported issues, because frankly I got overwhelmed with the feedback from the last release. Since than I've been going through the bugs and have been trying to meticulously identify each issue and address it. Not that there are show-stopping bugs in, but I want the 2.1.X version to be an improvement in stability as well as add something significantly new. There have been a whole lot of fixes since 432 (http://dl.covecube.com/DrivePoolWindows/beta/download/changes.txt) The next public BETA is my priority now that per-folder (and pattern based) balancing is implemented. Hopefully it won't take more than a few weeks to get everything tested and published. I'm also actively working on "Product 3" which will integrate very nicely with StableBit DrivePool and will add significant value to it. So there are some amazing things in the works for the future. Thank you for your continued support.
  4. Well guys this is now fully implemented, and very much untested Here's the change log for this feature: https://stablebit.com/Admin/IssueAnalysis/2165 You can download the latest internal (untested) BETA here: http://dl.covecube.com/DrivePoolWindows/beta/download Latest BETA is as of this writing. I'll have much more to say on how it all works in a future blog post, once I test it a bit more thoroughly and release a public BETA up on stablebit.com. But you can give it a whirl today if you're feeling adventurous.
  5. Piotr, I've examined your service dump and I believe that your crash is being caused by the Ordered File Placement plug-in v It seems to be stuck in a perpetual calculating loop. If you update that to the latest (v, I think that your issue will be resolved. But reboot your system prior to upgrading to get it "unstuck". Download it here: http://stablebit.com/DrivePool/Plugins In fact, I just looked at the change logs for that plug-in and I can see that Issue #76 was fixed in that version and it was specifically causing perpetual ratio calculation. In addition, I've made 2 changes to the StableBit DrivePool code: Balance ratio calculation should not run using IDLE thread priority by default. No balancers should ever be "trusted" to calculate the balance ratio quickly. There should be an enforced timeout for that calculation and if it expires a balancer should be aborted. If the updated balancer doesn't resolve your issue then you can download the latest internal BETA with those fixes from here: http://wiki.covecube.com/Downloads If you still continue to have the problem, you can request a remote support session here: http://stablebit.com/Contact Regards, IAR: https://stablebit.com/Admin/IssueAnalysis/2159
  6. Lurifax, Thanks for sending in that memory dump. I've analyzed it and unfortunately it indeed was a bug in build 420. It only affects x86 hosts, which is why you are seeing it. To resolve the issue you can download the latest public BETA right here: http://stablebit.com/DrivePool/Download Or you can get the very latest internal BETA here: http://wiki.covecube.com/Downloads (these contain the very latest fixes as people report them) I'm going to try to get 2.1 out as a release final sooner rather than later, so the fix will be in that as well. However, we have a few other important issues to address before that happens. IAR: https://stablebit.com/Admin/IssueAnalysis/2157
  7. Just to complete IAR 1154: I've done a number of controlled tests and didn't find any slowdowns. Full details here: https://stablebit.com/Admin/IssueAnalysis/1154
  8. I'll see if we can put in the Dashboard integration into the EXE setup package, like we do with StableBit DrivePool 2.X. (New CCR: https://stablebit.com/Admin/IssueAnalysis/1161 ) I'm currently experimenting with a "Metro" theme for the StableBit Scanner when installed on Windows 6.2+. You can see this in action in the latest internal BETAs ( http://wiki.covecube.com/Downloads ) I've fixed the case as well in the latest internal BETAs.( Completed CCR: https://stablebit.com/Admin/IssueAnalysis/1162 )
  9. This is a very interesting thread and I think that if there is a performance issue with StableBit DrivePool we need to narrow it down to one particular scenario. For example, as bblue has suggested in the original post, Hyper-V running WHS2011 with a few pass-through drives. As far as some of the other issues that have been raised, let me comment on those: The performance pane uses our file system driver to measure performance with some limited input from the Windows Performance Counters. Some of the earlier BETAs were combining our data with the Windows performance counters in a larger sense, but that type of presentation became a bit confusing and inconsistent. The StableBit DrivePool UI is meant to show you a quick overview of what's happening on the pool, so currently it uses its own high performance real-time logger that is only active when someone is looking at the performance data and some limited input from the disk performance counters to indicate disk activity. The balancing plug-in settings operate in the system service and have really nothing to do with real-time read/write performance. Of course, except for their ability to tell the file system to avoid certain disks (according to fill limits). For example, if you tell the system to use a disk that is connected over USB 2.0 (albeit, an extreme example), then you are slowing the pool down. The point being, there is no additional "load" or resource consumption necessary to impose certain balancing rules in real-time. Background balancing does consume resources, but if background balancing is not running, balancing setting alone do not require some extra "processing". This is the nature of the balancing system and it was designed like this for performance. As for background balancing, that is optimized to not interfere with existing I/O as much as possible. The reasons are as follows: The pool remains full accessible when balancing is running. You can safely shutdown and restart the system while balancing is taking place. You will never receive "Access denied" or any type of other "In use" error message due to balancing. The background balancer uses Background I/O disk scheduling, which allows the OS to gracefully throttle it if something else needs the use of the same disk. As a consequence, it will not operate at maximum throughput. This can be turned off if you wish using advanced settings (http://wiki.covecube.com/StableBit_DrivePool_2.X_Advanced_Settings). Ok, I think we're veering off topic a bit here, but I just wanted to make it clear that background balancing and background duplication throughput speeds are never at maximum throughput, by design. You can turn this off. As far as read / write performance, this has come up now and again. So far I've never been able to recreate a scenario, in a controlled test, that has shown the pool's performance to be slower. From a theoretical point of view, here's how writing works: An I/O request comes in from some application (or the network). This I/O request is associated with some open file (opened previously). It has some data, an offset and a length. We take this request and forward it to NTFS using a thin wrapper module, all done in the kernel. That's pretty much it. So from a purely architectural point of view, there should be no discernible delay. Now I started this post by saying that if there is a potential performance issue here, that we should concentrate on recreating one specific scenario. I think that if something is going wrong it most likely is not in the read / write path. Those things are just very straightforward. Renames are fairly complicated so they might be worth considering as the culprit. There is really no such thing as a "copy" rename in the kernel, so StableBit DrivePool always renames to the same disk which should be instantaneous. I'm going to try a test to see if I can reproduce the scenario as it's outlined in the first post. IAR: https://stablebit.com/Admin/IssueAnalysisPublic?Id=1154
  10. The Disk Performance area shows the top file operations that are operating on the busiest disks. The file at the top is operating on the disk with the most active I/O request (i.e. the disk which is the slowest to respond because of I/O load). Each file can either be read from or written to, so I guess I'm not understanding the request for showing "write files" vs. "read files". A file can either be written to or read from, it's still the same file.
  11. These are not auto nightly builds but are deliberately built after a Code Change Request (CCR) is completed (see: http://wiki.covecube.com/Development_Status#Development_Workflow). The build process is automatic and the publish is automatic. The difference between these internal BETAs and the BETAs that are published on StableBit.com is that the internal BETAs don't undergo any kind of functional testing before a build is published. The BETAs published on StableBit.com undergo basic functional testing and the installer's upgrade procedure is tested on every supported OS. This takes a bit of time to accomplish so it's only done for public BETAs.
  12. Alex

    Bad Sector

    That's a good suggestion. What the Scanner should probably do IMO in these cases is simply rename the bad file part to something else and let DrivePool's duplication system kick in and reduplicated the file. I'm always worried about deleting files. This way we retain all 3 file parts and the user can delete the bad one. I've flagged this as issue #86 and it will be fixed.
  13. Hmm... could be an optimization issue with the sector map drawing code. I'll take a look at reproducing this right now. We've got an unlinked IAR open for this issue (#88). IARs are our new workflow for handling bug reports and applying fixes. Normally, IARs are linked to contact requests @ stablebit.com/contact so you can get updates on your issues that way. I should really write a blog post about our new internal workflow for handling bugs Oh, and as far as logging performance issues in the UI, yes we do. We have a sort of built-in performance profiler in all BETA builds of the StableBit Scanner. It can be shown by pressing 'P' while the focus is inside the window. If you could take a screenshot of that, along with your sector map it would might me understand what's going on. I've attached an example of what this looks like.
  14. You have a good point, there really should be some kind of notification at the end of the removal process. I've added this to the roadmap: http://wiki.covecube.com/Development_Status#StableBit_DrivePool_2.X We will add this to the UI in the future. For now, you can look in the PoolPart... folder on the damaged drive that you just removed. Any files that were not migrated will still remain in that folder.
  15. Bad sectors will get remapped automatically by the drive without your intervention. I've experienced this first hand just a few weeks ago. Here was my experience: A Western Digital Green drive developed a single bad sector. The SMART data confirmed the bad sector that the surface scan has detected. I was notified promptly and began a file scan. The file scan revealed that no files were affected by the damage. At that point I left the system alone for a few hours and then decided to re-check the bad sector to see whether it was still bad. The sector turned green and the SMART data no longer reflected the bad sector. Whenever something tries to write to a bad sector, the drive will automatically swap in a new known good sector from the spare sector pool and take the bad sector out of service. This is done silently and automatically. This might have been what happened in your case. Normally, the Scanner will re-scan bad sectors automatically and flag them as good after some number of day (depending on your settings). Was it a false positive? One common cause of false positives is when you abruptly disconnect a drive while it is being scanned. This will cause the Scanner to flag the currently scanning sectors as bad (since they're unreadable), right before getting notified that the drive was unplugged. The Scanner will at this point flag those "bad" sectors as "unchecked". As far as your error reports: There is an issue trying to add a firewall rule for remote control. This looks like a COM issue in Windows. If you don't use Remote Control you can ignore this, or even turn that feature off in Scanner Settings. A drive seems to have been abruptly disconnected while it was being queried for its power status, before we query it for SMART data. At least on one occasion, the system drive did not report the controller that it was on. This is the strangest of the bunch. If these errors continue and impede functionality then open up a contact request @ http://stablebit.com/Contact , mention this post to get the case forwarded to me and we can do remote support.
  16. Performance considerations with StableBit DrivePool: For non-duplicated files with the default performance setting enabled, there should be very little overhead for read / write I/O on the pool. This is because all pooled I/O is processed in the kernel and our file system driver uses Neither I/O, Fast I/O, oplocks and a full suite of file caching. These are optional under the hood performance optimizations that are available to all kernel file system drivers and they are all implemented and utilized by our driver. While there is always some overhead introduced by any kind of software storage pooling / redundancy package, I don't expect our pooling solution to have any significant impact on performance, when comparing pooled vs. non-pooled I/O on the same physical disk. The network I/O boost feature may reduce peak throughput and introduce higher CPU usage. The network I/O boost feature was designed to increase responsiveness of media streaming clients on a busy server and doesn't necessarily increase maximum throughput. In other words, we prioritize network I/O read requests over local read requests. This requires us to perform some additional processing on each network read request and so it does consume some extra CPU resources. While this does introduce overhead, for all practical purposes, it really is minimal and should not impact file transfer speeds in any appreciable way. Here is another test on the pool with network I/O boost enabled (using the same setup as above): Version 1.3.1 OS Version: Windows 8 Processor: AMD FX(tm)-8350 Eight-Core Processor Date: 02/03/2014 Time: 12:19:20 Program Parameters: 0 High Performance Timer: 0.0000000698 Test File: \\\Pool-SpeedTest\NW_SpeedTest.dat Write Time = 7.5035405 Seconds Write Speed = 533.0816880 Mbps Read Time = 7.5083370 Seconds Read Speed = 532.7411440 Mbps Test File: \\\Pool-SpeedTest\NW_SpeedTest.dat Write Time = 7.1603575 Seconds Write Speed = 558.6313200 Mbps Read Time = 7.3564616 Seconds Read Speed = 543.7396640 Mbps Test File: \\\Pool-SpeedTest\NW_SpeedTest.dat Write Time = 7.6143740 Seconds Write Speed = 525.3222400 Mbps Read Time = 7.5884258 Seconds Read Speed = 527.1185520 Mbps Real-time file duplication will have an impact on write performance because we have to send all write requests to more than one disk. We do this in parallel by sending the request to multiple disks at the same time. Performance considerations with the StableBit Scanner: Active disk scanning will have an impact on other read / write I/O performance to the disk being scanned. How much of an impact depends on the StableBit Scanner settings. Background I/O priority scanning ensures that Windows tags the read / write requests issued by the StableBit Scanner with the Very Low I/O priority. I/O priority is utilized in the kernel by the storage drivers in order to prioritize read / write requests to and from the disk. Scan throttling will actively pause scanning when other disk activity is taking place on the disk being scanned. This works best when Background I/O priority scanning is enabled as well. Scan throttling has multiple sensitivities, Low, Medium and High. Low means that you want the StableBit Scanner to allow some other I/O to the disk without pausing scanning. High means the opposite.Scan throttling can also monitor for bus saturation conditions, whereby scanning of one disk is slowing down I/O requests to another disk that is on the same bus. If this is the case, scanning will be paused until I/O on the other disks subsides. Quick Settings in the Stablebit Scanner and performance impact: Desktop mode - Throttling (Med) and Background I/O are enabled. Scans happen at any time. Laptop mode - Throttling (Med) and Background I/O are enabled. Scans happen at any time, but only when plugged into an A/C outlet. Server mode - Throttling is disabled, background I/O is enabled. Scans happen only at night. Tablet mode - Throttling (High, no bus saturation detection) and background I/O are enabled. Scans happen at any time, they occur more often, but only when plugged into an A/C outlet. You can obviously tweak these to your linking, but the defaults should work pretty well. All in all the system is designed to be fully automatic and very hands off.
  17. Hey guys, I've set up and run a controlled test using the same tool of pool vs. non-pool speeds and StableBit Scanner vs. no StableBit Scanner. Here is how I set up the test server: Server to client connection is on a 1 gigabit link connected through 2 switches. Created 2 shares, one on the pool and one not on the pool. No file duplication enabled. Made sure that the non-pooled share is on the disk part of the pool with the most free space. This ensures that the same physical disk will be used to allocate the test file in both the pooled and non-pooled test cases. Initially, the server has the StableBit Scanner installed and started. Made sure that the StableBit Scanner is not actively scanning any disks at this time. StableBit DrivePool is set up with the default performance settings (no Network I/O boost). Made sure that nothing else is using the physical disk while the test is ongoing. All tests were performed with a 500 MB file. It is important to ensure proper test condition in order to prevent skewed results. Now I ran 3 tests on the non-pooled share from the client: Version 1.3.1 OS Version: Windows 8 Processor: AMD FX(tm)-8350 Eight-Core Processor Date: 02/03/2014 Time: 11:36:09 Program Parameters: 0 High Performance Timer: 0.0000000698 Test File: \\\NonPool-SpeedTest\NW_SpeedTest.dat Write Time = 6.7337975 Seconds Write Speed = 594.0184560 Mbps Read Time = 7.6298019 Seconds Read Speed = 524.2600080 Mbps Test File: \\\NonPool-SpeedTest\NW_SpeedTest.dat Write Time = 7.1907796 Seconds Write Speed = 556.2679200 Mbps Read Time = 7.7817525 Seconds Read Speed = 514.0230320 Mbps Test File: \\\NonPool-SpeedTest\NW_SpeedTest.dat Write Time = 7.4736517 Seconds Write Speed = 535.2135920 Mbps Read Time = 7.4989738 Seconds Read Speed = 533.4063200 Mbps Then I ran 3 tests on the pooled share: Version 1.3.1 OS Version: Windows 8 Processor: AMD FX(tm)-8350 Eight-Core Processor Date: 02/03/2014 Time: 11:38:09 Program Parameters: 0 High Performance Timer: 0.0000000698 Test File: \\\Pool-SpeedTest\NW_SpeedTest.dat Write Time = 7.2969775 Seconds Write Speed = 548.1721680 Mbps Read Time = 7.6963353 Seconds Read Speed = 519.7278800 Mbps Test File: \\\Pool-SpeedTest\NW_SpeedTest.dat Write Time = 7.1262697 Seconds Write Speed = 561.3034800 Mbps Read Time = 7.4837478 Seconds Read Speed = 534.4915520 Mbps Test File: \\\Pool-SpeedTest\NW_SpeedTest.dat Write Time = 7.2078453 Seconds Write Speed = 554.9508720 Mbps Read Time = 7.7060378 Seconds Read Speed = 519.0734960 Mbps Then I stopped the StableBit Scanner service and ran another 3 tests on the pooled share: Version 1.3.1 OS Version: Windows 8 Processor: AMD FX(tm)-8350 Eight-Core Processor Date: 02/03/2014 Time: 11:41:06 Program Parameters: 0 High Performance Timer: 0.0000000698 Test File: \\\Pool-SpeedTest\NW_SpeedTest.dat Write Time = 8.1331414 Seconds Write Speed = 491.8148800 Mbps Read Time = 7.6461024 Seconds Read Speed = 523.1423520 Mbps Test File: \\\Pool-SpeedTest\NW_SpeedTest.dat Write Time = 7.5164256 Seconds Write Speed = 532.1678400 Mbps Read Time = 7.5272389 Seconds Read Speed = 531.4033600 Mbps Test File: \\\Pool-SpeedTest\NW_SpeedTest.dat Write Time = 7.2955172 Seconds Write Speed = 548.2818960 Mbps Read Time = 7.5415770 Seconds Read Speed = 530.3930480 Mbps As expected, the speeds are roughly equivalent in all 3 cases. I'll post some more information about Stablebit Scanner / DrivePool performance shortly.
  18. Alex

    The Roadmap

    As of 1/28/2014, in an effort to streamline the development process and to centralize the management of planned feature requests I've moved the current development status to our development wiki. You can access it here: http://wiki.covecube.com/Development_Status In addition to implementing new features we now have a separate system for identifying and tracking existing issues. See the wiki page for a bit more on that.
  19. For unduplicated files, StableBit DrivePool forwards all file I/O to the individual disk that the file is on. If the file exists on more than one disks (i.e. is duplicated), then: All file modification requests (such as writing to the file, setting its attributes, etc...) go to all of the disks that the file is on. Read requests will either go to the first disk that the file is on (when read striping is disabled), or to one of the disks that the file is on, as determined by the read striping algorithm. A directory listing operation works by querying all of the disks in parallel. This will force NTFS to read the MFT directory indexes on all of the disks where the directory being listed exists. These indexes can be cached and can theoretically be served entirely from RAM. Opening a file is similar to a directory listing. This will tell NTFS to query its directory indexes on all of the disks part of that pool in order to locate the disks that contain that file. This also is done in parallel and can be served by the system cache. So in short, StableBit DrivePool may spin up disks in many circumstances, I haven't really done testing to see how often this is.
  20. The next BETA of StableBit DrivePool with reparse point support is here! Download: http://stablebit.com/DrivePool/Download Read about it: http://blog.covecube.com/2013/11/stablebit-drivepool-2-1-0-432-beta-reparse-points/
  21. Absolutely awesome. USB 3.0 and Zotac are amazing. This is why I wrote DrivePool
  22. Alex

    Websites down?

    Yes, absolutely temporary. The stablebit.com server is running on a dedicated Windows Azure box with an automatic DNS failover to another shared hosting account. Today, both failed for about a total of 4 hours. I'm not sure why the Windows Azure services failed, but restarting the servers fixed the problem. The backup host is experiencing a DDOS attack at this time and is still not working. stablebit.com is back up but bitflock.com is still down. I'm monitoring the situation closely. Sorry about the inconvenience.
  23. Ok, so reparse points have definitely been driving me nuts lately. I was planning on releasing the StableBit DrivePool 2.1 BETA about a week after the 2.0 final with reparse point support, but it's still not out and it's because of reparse points. I've been trying different architectures over the past few weeks and none of them panned out as expected. But today, I believe that I've finally got something that will work. It will support all of the various kinds of reparse points, it will be super fast and stable. So what are these "reparse points" you may be asking? Well, reparse points are the underlying file system technology that enable a whole suite of functionality. Mainly they are used for creating symbolic links, junctions and mount points. Essentially it's a way to redirect access from one file or folder to another. You may be wondering if I'm talking about a Shortcut? No, confusingly a shortcut is not a reparse point. So how many ways does Windows have to redirect files / folders? A lot. That's the problem! Here they are off the top of my head: A shortcut - A special file that is parsed by the Explorer shell that really links to another file somewhere else (as in a Start menu shortcut). Most people are probably familiar with this because it's readily available in the Explorer UI. Symbolic file link - A file that points to some other file somewhere else. Confusingly, Windows Explorer also calls these "shortcuts" in the file properties dialog. A symbolic link can be created by the mklink utility with no options. Symbolic directory link - These are relatively new, as they were introduced in Windows Vista. This is essentially a directory that points to another directory somewhere else. These can be created by using mklink /D. Directory junction point - These are very similar to "symbolic directory links", but they were available prior to Windows Vista. Again, it is essentially a directory that points to another directory somewhere else. Some people make the mistake that a junction is only capable of pointing to another directory on the same volume, and that's not the case. These can be created by using mklink /J. Mount point - Mount points allow you to designate a directory that will point to another volume. These are typically used to "mount" a number of drives as directories under some other drive letter, thus saving drive letters. These can be created from Disk Management. File hard link - Yet another way to make a file point to another file. However, this method can only be used to point a file to some other file on the same volume. These are created using mklink /H. Yes, that's a lot of ways that you can redirect files / folders in Windows. Try Googling these and you can see the confusion that ensues as to what the differences are between each. So what is the difference between all of these? Well, instead of pointing out the pros and cons, I'll tell you how each one of them works under the hood and you can decide for yourself: A shortcut - This is the most "user friendly" way of creating a file that points to another one. Even the name makes sense, "shortcut", imagine that. It's readily available from the Windows Explorer menus and works entirely in user mode. A special .lnk file is created that the user mode shell knows how to parse. In Windows Explorer, an icon with a little arrow is shown to you to let you know that this is really a shortcut. However, as far as the kernel and file system are concerned, there is nothing special about the .lnk file, it's just a regular file. Symbolic file link - Sometimes called a "symlink" or "soft link", this is a system that redirects one file to another, purely in the kernel. It involves some special metadata that is stored with the "source link" file that points to the "target destination file" and requires coordination between the file system and the Windows I/O Manager. This system uses what are called "reparse points". Symbolic directory link - This is exactly the same thing as a symbolic file link, but it works on directories. The reason why I separated the two is because symbolic directory links were not available prior to Windows Vista and they must be created differently. However, the underlying technology that enables this is exactly the same. This too uses "reparse points". Directory junction point - This is similar to a Symbolic directory link except that it is available prior to Windows Vista and uses an older technique. Technically speaking, the main difference between this and symbolic directory links is that directory junction points always point to an absolute path, while symbolic directory links can point to relative or absolute paths. Surprisingly, this too uses "reparse points", but not all reparse points are the same. I'll get to that soon. Mount point - These are implemented in the exact same way as directory junction points, except that they point to the root of some other volume instead of some other directory. These are implemented with the exact same "reparse points" as directory junctions. File hard link - This is purely a file system construct. Because of the way directory indexes work in NTFS, it is possible to add a file entry to a directory index of a file that already exists under some other directory. Essentially, you can think of the file as being in 2 (or more) places at once. While this is not quantum physics, it is NTFS. Each file has a "reference count" and that count is incremented whenever a hard link is created to it. When the count reaches 0, the file is deleted. No other kernel subsystem is involved and no "reparse points" exists. This is the cleanest and purest way of making a file appear in 2 places at once (IMO). Wow, and all this works together reliably? Yes, and that's what StableBit DrivePool is trying to preserve. You see, right now the only thing that we support on the pool from the above list are shortcuts. Everything else is not supported. Some people have been requesting the support of file / directory symbolic links and junctions. Those 2 can be used by software in order to create complex directory structures, in order to organize your data better. 4 out of the 5 unsupported technologies use "reparse points", so it makes sense for StableBit DrivePool to implement support for them. Ok, so what's a "reparse point"? A reparse point is a Microsoft defined data structure that gets associated with a file or a directory. When that file or directory has a reparse point associated with it, then it becomes a kind of link to "somewhere else". Essentially, when a file system encounters a reparse point, it tells the I/O Manager "these aren't the droids you're looking for, go look here". The I/O Manager is responsible for opening files, so it happily obliges. That doesn't sound too complicated Well, it isn't, except that there are different types of "reparse points" and each reparse point has a different meaning of where to go next. For example: File / directory symbolic links use a "symlink" reparse point. Directory junction points / mount points use a "mount point" reparse point. Any 3rd party developers can develop their own type of reparse points and their own logic as to how they work. Remember drive extender from WHS v1? Yep, those tombstones were yet another kind of reparse points. Ok, so this is complicated. But will StableBit DrivePool support reparse points? I'm working hard towards that goal, and the reason why I'm writing this is because I believe that I've finally cracked the architecture that we need to support all Microsoft and 3rd party reparse points on the pool. The architecture has these positive aspects to it: It supports file / directory symbolic links, directory junction points, mount points, and 3rd party reparse points on the pool. It is a 100% native kernel implementation, with no dependence on the user mode service. It follows the 0 local metadata approach of storing everything needed on the pool itself and does not rely on something like the registry. This means that your reparse points will work when moving pools between machines (provided that you didn't link to something off of the pool that no longer exists on the new machine). Some of my previous attempts had these limitations: Requires the user mode service to run additional periodic maintenance tasks on the pool. No support for directory reparse points, only file ones. Adding a drive to the pool would require a somewhat lengthy reparse point pass. The new architecture that I came up with has none of these limitations. All it requires is NTFS and Windows. When will it be ready? I'd hate to predict, but I think that it should be deployed in BETA form in a few weeks.
  24. Alex

    BitFlock Disruption

    Today we've had a BitFlock disruption. BitFlock.com was down for about 6 hours becasue of a domain name issues. All access is now restored and you should not experience any further issues accessing bitflock.com. The problem was at Google.
  • Create New...