Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - adridolf

Pages: [1] 2 3 ... 8
General Discussion / Re: How do I identify a UoR?
« on: January 28, 2019, 07:44:27 am »
I think negative error codes are OS error codes in FlexRaid. Maybe there is some info in the Event Log (if Windows) or similar?

General Discussion / Re: switch to tRAID?
« on: January 28, 2019, 07:41:19 am »
Yes, that's how it is: You may have to come across several obstacles when trying to recover data in case of disk failure, but you CAN do it. I especially like tRaid for the capability to access data when something is "wrong", and furthermore for having X-1 disks still left even if I can NOT recover the failed one.
My biggest concern is actually when I have to upgrade my system at some point where I require license transfer. I would still use tRaid if I set up my system anew, however it seems harder to get a license today ...

RAID-F on Windows / Re: DRU restore failure
« on: January 28, 2019, 06:31:18 am »
Hi, I had a similar problem once, but for t-Raid, not for RAID-F. However, the central problem was a changed system disk (as in your case), which messed up the configuration, since the references to the old disk where still in the configuration and FlexRaid was not capable to deal with that. I had to wipe all remaining pieces of information regarding this disk from the config and then was able to do my restore. Note that in my case, however, the changed disk was NOT part of the data covered by FlexRaid, so I could mess around with it.

General Discussion / Re: Registering an offline disk results in error
« on: December 04, 2018, 03:56:10 pm »
During a complicated disk restore, I'm facing a similar problem as in this very old thread:
If I set the target disk to restore to offline, I get similar errors as in the initial post.
If I set the target disk to restore to online, Rebuild seems to work (at least it started with reasonable speed and without errors).

The question:
How can bring a disk offline "with tRaid"? At the moment, I'm not really sure whether my OS will interfere with the disk being restored while in online state ...

Though I cannot answer your question, note that tRaid seems to be the more reliable product (in terms of what can/cannot do without jeopardizing your sync state). So take your time to decide on this ...

tRAID Bug Reports / Re: Notifications for dropped drives?
« on: May 03, 2018, 05:47:46 am »
The WebUI "service" must be running.

General Discussion / Re: Presale Questions
« on: April 25, 2018, 05:03:38 am »
While FlexRaid has some unique features, support is the downside in many cases.

Note that RAID-F is the "older" part of it (mirroring on file level), while t-Raid is the "newer" one (mirroring on disk level).

In addition, t-Raid has at least seen some activity over last two years, while RAID-F users more frequently complain about features not being fixed or supported any more.

I use t-Raid because of its ability to add/remove drives without having to set up everything again and due to the possibility to access my data from individual drives if something goes wrong. These are killer features for me which kept me living with the slow development and sometimes problematic support (although I personally did have much less problems in this area than others) as well as the very user-unfriendly licensing concept.

If you need one of those features, maybe you should consider using RAID-F or better t-Raid. If you don't or you are (actually) dependent on support, try something different. Also, be aware that paid premium support seems to not help you much based on what I read here.

General Discussion / Re: License help no key has been sent
« on: April 24, 2018, 06:04:14 am »
Seems to be normal. Try again and again until you get some response ...

Your problem is the partition table:
All the partitions on a drive are listed/registered in the so-called master boot record (MBR). The MBR can cover 2^32 sectors, one sector has 512 bytes; thus, HDDs with an MBR can only "access" 2^32 times 512 bytes, or 2 TiB. Thus, for bigger drives there is the so-called GUID partition table (GPT), which can cover bigger drives (and is also bigger itself).

Your original drive was smaller than 2 TB, and thus (I suppose) formatted with MBR (which is default). During restore, the MBR was copied to the new disk. You then resized the 1.5 TB partition to 2 TiB, which was the maximum possible with MBR.

There is no built-in way to convert from MBR to GPT WITH partitions on the disk; WITHOUT data, conversion can be done easily. This gives you different choices of what to do:
1. You can back up your data on this drive to a spare one, remove the partition, switch to GPT, recreate a bigger partition, and copy data back to the drive. This requires the same setup as the Extension (pool off, array on) and can be done with Windows Disk Management, all on the transparent drive again. Thus, parity will be kept up to date; the data you copy off won't be protected during the process (obviously) and the copying will create (some) stress to the parity drive. [If you're clever, COPY the data from the drive, do not MOVE it. Thus the first half of the procedure will only be reading (not affecting parity), while MOVING would imply changes and stress parity. The partition deletion then is only a change in the MBR, so a very small write.]
2. You just live with drive being 2 TB instead of 3 TB. Parity will work, you will have least to do.
3. You use a partition manager which offers MBR to GPT conversion. This will cost you money (except you already have one). In addition, those tools do low-level things with disks; there is a chance that tRaid won't like this. Additionally, it may be harder to identify the transparent disk. (I would not go this way, but it is possible)

What do we learn from that: ;-)
If you don't plan to use them as system disks, initialize disks with GPT in the first place ...

After having replaced the drive, tRaid rebuilds the data on it exactly as they were before. This includes partition info, including the partition size.

If the rebuild is completed successfully (!), you can do the following:

First disable the pool (just the pool, the array should remain up).

Now find the transparent drive corresponding to the new disc in the Windows Device Manager: It should be easy to find in your case, as it will be a 3 tb device with a 1.5 gb partition on it. Note that you have to choose the TRANSPARENT drive (looking normal with partition on it) and NOT the physical drive (which should be marked "offline"). If you see only one 3 tb drive (which is offline), then your tRaid array is not running.

Having identified the correct drive in device manager, just resize the partition to the full size (option "Expand Volume" if I remember correctly) like you would do for any regular drive and you are done. tRaid will synchronize the partition change, since it synchronizes the whole drive.

After that, just reenable the pool again (in case you disabled it earlier).

General Discussion / Re: Verify Raid Failure - Repeated
« on: January 06, 2018, 05:27:27 pm »
Note that I did the initialization with Server 2012 (or 2012 R2) and I had the same issues with GPT PPU. However, I do not think that I have more than 1 MB at the end.

General Discussion / Re: Verify Raid Failure - Repeated
« on: January 06, 2018, 05:53:37 am »
Regarding the bigger than 2 TB topic:
This limit refers to the size which can be PARTITIONED, so where you can place partitions. The PPU, however, is just bits build by some kind of checksum algorithm. It does not require partitioning.

The problem with GPT is that the section of the HDD supposed to contain the partition table is too small for the whole GPT information (but MBR fits). Therefore, a dedicated GPT partition is created on the disk. This is what I suspect to interfere with the data written by tRaid. At the section where the GPT partition is located, tRaid wants to place the checksum of the GPT partitions of the DRUs (which for itself might not be a valid GPT partition and thus is corrected on boot).

How to deal with that:
Stop the array, go to Disk Management (Windows) and reinitialize the PPU to MBR (rightclick the disk information there). Be sure to choose the correct disk, otherwise your data will be lost. Then restart the array. Start Specific range operation->Verify/Sync for the first and last 10 GB of the array. (Keep in mind that the "end" of the disk/array is not 4 TiB (1024^4 B), but 4 TB (1000^4 B), but tRaid thinks in TiB. So you have to calculate 4/(1.024^4) TB or 4000/(1.024^3) GB; or you can use the reported error in bytes (and start a little bit before that point) and devide the value by 1024 three times to get GiB.
After the Verify/Sync you should be fine, as only the beginning and end is affected and you do not need to resync everything.

General Discussion / Re: Verify Raid Failure - Repeated
« on: January 02, 2018, 01:59:45 pm »
Look here:

Can be addresses by reinitializing the PPU from GPT to MBR. Read the whole (!) bug report with comments, this should help you with your issue. If not, I would be interested in the follow-up.

News and Updates / Re: Forum Mails sent after ages
« on: December 07, 2017, 09:12:01 am »
Today, I again received a bunch of mails from June.

Maybe have a look at how the e-mail notifications are processed. We once had a similar issue with a Mantis, until we changed sending mails to a cron running every minute.

Official releases / Re: FlexRAID tRAID 1.1 Final (new release 2017-11-24)
« on: December 05, 2017, 05:49:58 am »
I can report that so far everything seems to work on Windows Server 2012 R2.

Updated from the latest preview release.

In the log file, the version is missing.
Old: [2017-11-28 15:22:41.989792][1524]|||||||||||||||||||||||||  NZFS Service Start v1.0.0 2017.01.28  |||||||||||||||||||||||||
New: [2017-11-28 15:34:35.325688][3088]|||||||||||||||||||||||||  NZFS Service Start vC  |||||||||||||||||||||||||

Pages: [1] 2 3 ... 8