Alex
-
Posts
253 -
Joined
-
Last visited
-
Days Won
49
Posts posted by Alex
-
-
I like writing these posts because they give me feedback as to what the community is really interested in. I can see that my last post about the Scanner was not very interesting, it was probably too technical and there's probably not much to add to what I've already said.
Well, this time let's talk about StableBit DrivePool. In particular, I'd like to talk about DrivePool beyond 2.0.
Controlling Folder Placement
I think that I have a few great ideas for DrivePool 2.1+ but some of them depend on the ability to control folder (or file) placement, per pool part. I've kind of hinted at this capability in the thread that talked about taking out per-folder duplication, but I think that I've figured out how we can make this work.
What I would like to be able to do in future versions is to give you guys the ability to associate folders with one or more disks that are part of the pool. So that any files in those folders would be stored on those pool parts only (unless they're full).
This should be trivial to implement on the file system level, but the balancing framework would need to be enhanced to support this, and I think that I've figured out how to make that work.
Theoretically, you should even be able to use wildcard patterns such as /Virtual Machines/Windows* to associate all of those files with a group of pooled disks.
What do you guys think, is this worthwhile doing?
- meeldilla and Tardas-Zib
-
2
-
Alex, I "saw" [heard] you being interviewed on utube "StableBit on Home Server Show 219".
Very good representation of the product. Yes, I know it was from April but I just found it this morning.
Oh and thank you
I'm no expert at public speaking, but I do like to talk about the products that I've built, which I believe in very strongly.
-
I do the math every year or so. Any serious online storage [TBs] cost more than buying and rotating drives every three years, which of course I haven't had to do that frequently.
You can check for yourself, how much does it cost for 55 plus TBs online 24/7?
Well, I wasn't particularly talking about cloud storage here, but perhaps just a way to synchronize settings / history among different machines.
But now that you mention cloud storage, this really is something that I've been thinking about.
What if we could bring the cost of cloud storage down to something reasonable, where it would be practical to purchase TBs of storage? I have been doing some math and I think that the main problem seems to be bandwidth more than the actual cost of storage.
-
Just to follow up on this,
I've done extensive troubleshooting on this issue with Kihim in a support ticket. It seems like this is caused by the system getting bogged down at certain times leading to a periodic slowdown in the UI. At least that's what I can see from the Scanner's built-in UI performance profiler (accessed by pressing P in a BETA build).
I don't see any Scanner UI task running away with the CPU. I've also set up a local test rig with similar specs, 26 disks and a 2Ghz 8-core AMD server, and have run the Scanner UI for hours looking for any slowdowns and I couldn't find any.
But I think the bottom line here is that the Scanner uses WPF to render its UI, and WPF does require some more CPU resources than your typical Win32 application. I think that that's really the core issue here. So in the future I would like to offer a "lite" version of the UI for situations where CPU resources are scarce. I imagine that there will be a simple drop down that will let you switch between "standard" and "lite" versions of the UI, letting you run whichever one you want.
-
Kihim,
I've looked at the DrivePool dumps and it's pretty clear that the DrivePool service is waiting for a WMI query to return. The query is intended to synchronize disk metadata between the StableBit Scanner and StableBit DrivePool.
It looks like this:
Management scope: root\StableBit\Scanner
SELECT * FROM Disks WHERE DeviceIndex = "..."
I would need to see a memory dump of the Scanner.Service.exe when it is in this locked up state, in order to understand why it has locked up. Perhaps it's for the same reason, a stuck WMI query. The Scanner does query WMI whenever it detects a new disk, which would make sense in your case, since you're swapping disks.
-
Pal,
The problem was probably corrected by chkdsk before the Scanner could get to it. The problem here is that if the Scanner detects damage, and then you (or some other app) runs chkdsk to repair the problem, the Scanner is not notified.
This is something that I'm working on improving, although I'm not sure how it can be fixed.
In any case, there is no harm in what you did. The Scanner simply ran chkdsk and chkdsk told it that all is ok.
As far as chkdsk logs, no, the Scanner doesn't keep a log of that anywhere. But this is not a bad idea. I've added this to the todo list and it will be implemented in the future.
-
I may have missed the memo, but what's the road map for version 2, now since it has dash board integration with WHS 2011, and other variants, is the idea here for V2 to ultimately replace V1? Seems that would be the logical path from stablebit, once there's a final, stable release, doesn't make much sense to continue supporting two Rev's of the product for the same platform.
As far as WSS is concerned (WHS 2011, WSS 2012 and R2), 2.0 doesn't fully replace 1.X. We will continue to rev 1.X for time being. In fact, there should be a new version of 1.X coming up in the next few weeks.
In short, for now 1.X is targeted at WHS 2011 users (and similar).
So what doesn't 2.X support? In particular 2.X doesn't support the following for WSS (which 1.X does):
- No Dashboard notifications.
- No WSSX installer.
- It doesn't understand server backup disks and OS partitions and will allow you to add them to the pool.
So in short, 1.X was deeply optimized for the WSS platform, while 2.X was optimized for the standard Windows platform.
Yes, with time 2.X will become a 100% replacement for 1.X, but for now we will maintain both versions.
----
As far as what's next for StableBit DrivePool in general, well it's something really exciting, but I can't really say any more than that
-
You're right, the temperature in DrivePool was not respecting the C/F setting in the Scanner. This has already been fixed in the latest builds of DrivePool 2.X but it requires a new build of the Scanner which have not been built yet. The next build of the Scanner will have the necessary code to make this work.
So in short, this will resolve itself with some time and a newer build.
-
JSox,
Hi, I'm the developer. The temperature history is something that the drive maintains itself. Not all drives maintain this history so you won't see it for every drive.
This is part of the "SCT" standard and the StableBit Scanner is able to parse that information and display it in a graph. In addition, we can tell the drive to change its sampling interval.
regards,
-
Hmm. I wonder if there's a market niche yet for a "CloudPool" product, with balancers to take advantage of provider price/latency/speed/quota disparities and automatically dupe/sync/shift your data accordingly. And since we can now rent VM space, you could have CloudPool itself running in the clouds along with its data. Ultimately, you might have "Pool", a product that automagically handles all of your storage and processing resources, both local and remote.
I think that this is where we're trying to go.
It just takes time and we need the support of our customers to get there.
Ultimately there should be no difference in local vs. remote storage, in terms of accessibility. "CloudPool" is our goal.
-
Hi Alex,
On my side, I would not really be interested by such a feature.
I do not find that very useful, especially today where you can RD your server on your android mobile...
For the moment I can only think about one network related feature that would really have interest to me: pool recycle bin handling share deletions (same kind as greyhole over samba).
Ok, point taken.
No cloud for us
-
Keeping this board on topic, I'd like to talk about something pretty technical that is central to how the StableBit Scanner operates, and perhaps get some feedback on the topic.
One of the benefits of running the StableBit Scanner is not just to predict drive failure, but to prevent it. The technical term for what the StableBit Scanner performs on your drives to prevent data loss is called Data Scrubbing (see: http://en.wikipedia.org/wiki/Data_scrubbing). By periodically scanning the entire surface of the drive you are actually causing the drive to inspect its own surface for defects and to recognize those defects before they turn into what is technically called a latent sector error (i.e. a sector that can't be read).
In order to do the periodic surface scan of a disk, the StableBit Scanner needs to know when it scanned a disk last, which means that it needs to identify a disk uniquely and remember which sectors it has scanned last and when. The StableBit Scanner uses sector ranges to remember exactly which parts of which disk were scanned when, but that's a whole other discussion.
I would like to focus this post on the issue of identifying a disk uniquely, which is absolutely required for data scrubbing to function properly, and this was overhauled in the latest BETA (2.5).
The original StableBit Scanner (1.0) used a very simple method to identify disks. StableBit Scanner 1.0 used the MBR signature to differentiate disks among each other.
For those who don't know what an MBR signature is, I'll explain it briefly here. When you buy a new disk from the store, it's probably completely blank. In other words, the disk contains all 0's written to it throughout. There is absolutely nothing written to it to differentiate it from any other disks (other than the serial number, which may not be accessible from Windows).
When you first connect such a blank disk to a Windows machine it will ask you whether you want to "initialize" it. This "initialization" is actually the writing of the MBR (master boot record, see: https://en.wikipedia.org/wiki/Master_boot_record), or GPT (GUID Partition Table) if you so choose. The MBR and GPT define the header (and perhaps footer) of the disk, kind of like when you write a letter to someone and you have a standard header and footer that always follows the same format.
One of the things that initializing a disk does is write a unique "signature" to it in the MBR or GPT. It's simply a long random number that identifies a disk uniquely. The problem with a MBR signature is that the random number is not large enough and so it is only meant to be unique on one single system. So if you connect a disk from a different computer, the disk signature on the foreign disk has a miniscule chance of being the same as a disk on the system that its being connected to.
Well, for the StableBit Scanner 1.0 this would be a problem. It would recognize the new disk as being the old disk, which would cause all sorts of issues. For one, you can't have the same disk connected to the same computer twice. That's simply not possible and we would write out an error report and crash.
StableBit Scanner 2.0 improved things a bit by utilizing the GPT signature, which was guaranteed to be unique across multiple systems. The only problem with using the GPT disk signature to identify disks uniquely is that disk cloning software is capable of placing the same signature on 2 different physical disks which would end up causing the same problem. In addition, many disks still utilize MBR, so we can't solely rely on GPT to resolve this issue.
As you can see this has not been an easy problem to solve
In the latest StableBit Scanner 2.5 BETA I've completely overhauled how we associate disk scan history (and other persistent settings) with each disk in the system. This is a major change from how things used to work before.
In 2.5 we now have a brand new Disk ID system. The Disk ID system is heuristic based and picks the best disk scan history that it knows of based on the available information. We no longer rely on a single factor such as a MBR or GPT. Instead, we survey a combination of disk identifiers and pick the disk scan history that fits the available data best.
Here is the list of factors that we use, starting from the highest priority:
- Direct I/O disk serial number
- GPT Signature + WMI Serial number + Disk size
- GPT Signature + WMI Model + Disk size
- GPT Signature + Disk size
- MBR Signature + WMI Serial number + Disk size
- MBR Signature + WMI Model + Disk size
- MBR Signature + Disk size
See the change log for more info on what this change entails. I hope that you give the new build a try.
This post has definitely been on the technical side, but that's what this forum is all about
Let me know if you have any comments or suggestions (or can find a better way to identify disks uniquely).
-
Just to update you guys on this, thanks for the feedback. I got a bunch of feedback on this issue both here and through the standard support channel @ stablebit.com/contact
I will be adding >2 duplication count support to the UI post 1.0 release final.
Right now it is perfectly normal to use >2 duplication counts using dpcmd because both the file system and the service were designed to understand any arbitrary duplication count.
It's only the UI that doesn't understand duplication counts of >2, but that can be updated. For now, all duplication counts >2 will show up as x2 in the UI but this is a purely a cosmetic issue.
-
I've been debating how to handle automatic updates while we're in BETA.
There are 2 issues I think:
- Too many updates are annoying. (E.g. Flash)
- Because this is a BETA there is the potential for a build to have some issues, and pushing that out to everyone might not be such a good idea.
So I've come up with a compromise. The BETA automatic updates will not push out every build, but builds that have accumulated some major changes since the last update. Also, I don't want to push the automatic update as soon as the build is out because I want to give our users the chance to submit feedback in case there are problems with that build.
Once we go into release final, then every final build will be pushed out at the same time that it's published.
-
I've looked at the dump that was referencing this thread and this has already been fixed and the fix will be available in the next public build.
-
Joe,
I'll try to add the ability to limit automatic scanning to days of the week or days of the month in a future build.
Thanks for the suggestion,
-
We can set up a remote support session on this if you'd like. I'll log into your server and take a look at the problem.
I'll private message you the details in a second.
-
Good to know that this is resolved. Build 320 resolves a bug that was (unfortunately) introduced in 312 which I think was responsible for this and some other issues that people have been reporting.
-
I am currently evaluating Drivepool and Drivebender and I notice that you both have the same problem with Server backups in that you both backup duplicates. So I will ask the same question here that I asked over there, how hard would it be to put the duplicates in a completely different folder structure so that it is easily unchecked when choosing which folders to backup? This new folder would, preferably, be outside the poolparts folder, or if it is inside that folder it could be like poolpartsxxx/duplicates. This way we can just unselect one folder and it removes all the duplicates from the backup.Thanks and I look forward to your response.
If you are looking for a way to backup only the "master" copy of a file and not the duplicated part, then that is not possible.
DrivePool has no notion of a master copy vs. a backup copy. Each copy of the same file is exactly identical, and the copies can reside on any pool part.
If you want to backup your duplicated pooled files without backing them up twice, you will need to use a backup solution that does deduplication (E.g. the client computer backup engine part of the Windows Home Server 2011 / Windows Server 2012 Essentials). Alternatively you can use a file based backup system to backup directly from the pool (such as SyncBackSE)
-
JazzMan,
Simply put, it is much harder than I initially thought to make a reliable implementation of symbolic links.
As far as I can tell, we can make a reliable implementation in the future, it's just going to take some time.
Look for this in a future build.
Regards,
-
Thanks for testing it out.
My initial implementation in build 281 above was based on the premise that we can reuse the reparse functionality that's already present in NTFS.
I've been reading up some more on exactly how this is supposed to work and playing around with some different approaches, it looks like the entire concept of reusing NTFS for this is not going to work.
So don't use build 281
I'm going to take the current reparse implementation out and rewrite it from scratch using a different approach.
Using this new approach, reparse points (or symbolic links) will appear as regular files or directories on the underlying NTFS volume, but will work like reparse points on the pool. This will also eliminate the burden of accounting for reparse points when duplicating or rebalancing, since they will be regular files on the underlying NTFS volume.
Look for that in a future build. I don't think that it will make it into the next build because that one is concentrating on updating the locking and caching model, which is a big change as it is.
-
Guys, I've added preliminary support for symbolic links (reparse points). It still needs more testing, but here is the internal build with this feature:
-
What a fantastically detailed reply. Thank you!
A couple of follow-up questions:
1. When the standby timer checkbox is semi-selected (grey), what does that mean?
2. Would you recommend that I use Windows to put the disks in standby, or the disk firmware functionality?
- Because there is no way to query the disk for its current standby settings, the checkbox defaults to an indeterminate state.
You can only set standby.
- I would suggest that if you would like to set different standby times on a per-disk basis then use the firmware, but if you just want a single standby time for all the disks then use Windows.
- Because there is no way to query the disk for its current standby settings, the checkbox defaults to an indeterminate state.
-
This is actually a fairly complicated topic.
Let's start by talking about how normal standby works without the StableBit Scanner getting involved.
Windows "Put the Disk to Sleep" Feature
Normally, Windows will monitor the disk for activity and if there is no disk activity for some preset amount of time it will put the disk to "sleep" by flushing all of the data in the cache to the disk and sending a special standby command to it. At the same time, it will remember that the disk is asleep in case any other application asks.
Shortly after the disk goes to sleep, the StableBit Scanner will indicate the fact that the disk is asleep in the Power column. Normally, the Scanner gets the power status of the disk by querying Windows and not the disk.
It does not query the disk directly for the power state because Windows considers this power query disk activity and wakes up the disk as a result.
Now, things get a bit more complicated if you want to include the on-disk power management in this picture.
Disks can optionally support these features, which can put them to sleep without Windows knowing it:
- Advanced power management.
- Standby timer
Advanced Power Management
This is a technology that implements power consumption profiles. For instance, if you don't care about performance but want maximum power savings, then you can tell your disk just that. Simply set the Advanced Power Management to Minimum Power Consumption. Or you can do the exact opposite by setting it to Maximum Performance (which guarantees no standby).
With Advanced Power Management you don't concern yourself with "sleep timeouts", like in Windows. You simply state your intent and the disk will adjust various parameters, including the standby time, according to your setting.
The implementation of Advanced Power Management is completely up to the manufacturer of the drive, and there are no specifications that explicitly state what each power mode does. This entire feature may not even be supported, depending on the disk model.
Standby Timer
The Standby timer is more widely supported because it is an older feature. You simply specify after how much disk inactivity you would like the disk to be put to sleep. This is similar to how things work in Windows, except that the low power mode will be initiated by the disk firmware itself.
Again, the implementation of this is up to the manufacturer of the drive.
StableBit Scanner "Put into Standby"
In the StableBit Scanner, you can right click on a disk and put it into standby mode. What this does is send a power down command to the disk. This type of power down is equivalent to what Advanced Power Management or the Standby Timer would do.
More importantly, when a disk is powered down in this way, Windows will not be aware that the disk is in a low power state, and will continue to report that the disk is still powered up. This is not an issue because the disk will simply spin up the next time that Windows tries to access it.
But this leaves the StableBit Scanner with a dilemma. If we can't query the disk for the power state directly, how do we report the true power state of the disk? What the StableBit Scanner implements is a power state in which it's not sure whether the disk is in standby or active, and this is what you were seeing.
Forcing the StableBit Scanner to Query the Power Mode from the Disk
If you want to use on-disk power management exclusively, and you don't care about Windows putting your disks to sleep, you can instruct the StableBit Scanner to query the power mode directly from the disk.
When this is enabled, you will no longer see the standby or active message, but Windows will never try to put that disk to sleep. That's why this is off by default.
SMART
And just to make things even more complicated, sometimes a disk will wake up when it's queried for SMART data.
To this end the StableBit Scanner implements some more settings to deal with this:
I hope that this clears things up.
Nuts & Bolts Google+ Hangout
in Nuts & Bolts
Posted
I'm thinking about doing a Nuts & Bolts Google+ hangout in the future. Basically, it would be an open discussion about anything Covecube / StableBit, current or future products, and technology trends (no tech support though).
But I'm not sure how many people would participate in something like that.
Would anyone like to participate?