unRAID Server Release 6.0-beta7-x86_64 Available

[dalben]

I am assuming that this is still not safe to use on my main server?

 

I migrated my one and only server over to 6.07

 

No show stoppers so far.

[PeterB]

I am assuming that this is still not safe to use on my main server?

 

I've been using v6.0 betas 4, 5a and 7 on my one and only server, without any significant problems.

 

I did try b6, but reverted when I found it crashed my virtual machines.

[jphipps]

I am assuming that this is still not safe to use on my main server?

 

I have been running the betas since 6b1 and am running on beta7 and have about half my drives coverted over to XFS or BTRFS and I haven't encountered any real issues...

 

Of course there is the normal disclaimer... It is a beta still, so there are some risks...

[SSD]

It is important to keep in mind, when trying to decide when and if to use a beta, what features are new and improved in the beta, and which are tried and true. Beta 7 introduces new filesystem options and people should be cautious to test these features before fully relying on them. There is a new Docker version which means little to unRaid.

 

But side effects can and do happen, so the betas are a risk. But the release versions would also be a big risk if we didn't have a fair number of brave souls that move to the betas and run then through their paces in a regular basis.

 

I'll add one more comment. The forum has complained about the timeliness of LimeTech in pushing our betas and releases on time. And these arguments have some merit historically. But LimeTech has never, in my memory, released a bad beta that corrupted anyone's data. Non professionals do not realize how hard it is to do good internal testing of a software product. Not sure what they do but hope they keep doing it because, by the time betas come out, they are pretty darn solid. (Of course now that I say it Murphy will rear his ugly face so beware! )

[Frank1940]

I am assuming that this is still not safe to use on my main server?

 

At this point with the version 6.0 betas, is that you have to have the time and patience to devote to keeping track of any issues and their possible effect of those issues on your situation.  You also have to commit to continuing on the upgrade path until the beta period ends with a stable release.  You can't stop half way through and say, "it works good enough for me at this point."  Otherwise, you could become one of those persons with a major problem and running a beta version that is releases back and no one has a clue of how to help you out of the problem.

[StevenD]

Tom, can you elaborate on this one ...

- emhttp: removed automatic file system expand when small drive is replaced by bigger drive.

 

Does this mean that if you are upsizing a disk, say from 2T to 4T, the 4T would continue to be limited to 2T? Can it be manually expanded? Will beta8 detect this condition and auto-expand any replaced disks? Would you advise users to boot back into 6b6 to do the replacement?

Code used to just do an unconditional "resize" upon every mount, and that was not an issue because with reiserfs it just was a no-op.  But with btrfs/xfs there needs to be a little more sophistication in the coding.  I didn't want to delay beta7 another week to get this in, so left auto-resize out until next release.  If someone needs to do an expansion before beta8 I will post instructions.

 

Somewhat related - if you add a btrfs or xfs disk in 6b7, can you boot back into 6b6? (I realize the XFS and BRTFS disks would appear unformatted and their contents not accessible, but would parity be maintained and therefore ability to do a disk rebuild?)

Yes.

 

Did these instructions get posted?  I'm not finding them and I need to upsize a drive today.  Thanks!

[bkastner]

It is important to keep in mind, when trying to decide when and if to use a beta, what features are new and improved in the beta, and which are tried and true. Beta 7 introduces new filesystem options and people should be cautious to test these features before fully relying on them. There is a new Docker version which means little to unRaid.

 

But side effects can and do happen, so the betas are a risk. But the release versions would also be a big risk if we didn't have a fair number of brave souls that move to the betas and run then through their paces in a regular basis.

 

I'll add one more comment. The forum has complained about the timeliness of LimeTech in pushing our betas and releases on time. And these arguments have some merit historically. But LimeTech has never, in my memory, released a bad beta that corrupted anyone's data. Non professionals do not realize how hard it is to do good internal testing of a software product. Not sure what they do but hope they keep doing it because, by the time betas come out, they are pretty darn solid. (Of course now that I say it Murphy will rear his ugly face so beware! )

 

I agree with this. People need to understand that UnRAID has protected their data the same way for years - so there is really very little risk when it comes to data loss. The introduction of new features such as new file system options increases the risk to a degree, but it's still fairly small when following the recommended advice.

 

The largest reason for people to try out the betas (along from helping UnRAID) is it gives users a chance to see how the new version works for them, in their specific environment. If they want a voice in how UnRAID progresses and how it's developed to meet their requirements they need to be willing to step up and try the new version out while it's still in development.

 

It's no good to wait for 6.0 to become final and then chime in with "man... I wish it did X differently". Now is the time to test and let your voice be heard. You may still not get the features you want, for a variety of reasons, but at least you've made a conscious decision to help make UnRAID the best product it can be for you, and everyone else.

 

With all that said, users do need to understand that with 6.0 being the first 64-bit release, it will require rework of all their plugins (either with new 64-bit plugins or docker containers). This is not necessarily a trivial upgrade, and needs to be made with a full understanding of what's involved. However there are already lots of others who've charted the path and are available to assist those in need.

[hackztor]

I always use the latest version even on production server mainly because as said above, I have never seen a beta corrupt or delete data. The betas have always been pretty stable, the biggest issues I ever seen were the whole fiasco with realtek nic drivers and it kept going back and forth. That said if you want to test file system out, make a backup of one drive and change only that one drive to a new file system (or backup all drives if possible/cost efficient). Then you could help participate with minimum risk.

[meep]

I am delighted to report that the the issue I observed in beta6 regarding Marvell SATA controllers appears to have been resolved;

 

http://lime-technology.com/forum/index.php?topic=33802.msg315935#msg315935

 

All my drives show up OK in beta7 and my Xen VMs restarted perfectly.

 

Thanks LimeTech!

 

Peter

[dlandon]

Sorry if this has been talked about already.  I try to keep up, but may have missed this.

 

Has anyone tried cache pooling in 6b7?  Is there a guide or information on how to set it up?  All I find is information on how to set it up in 6b6 using the command line.

 

Or is it not ready for prime time yet?

[pras1011]

Is there any benefits of using the 64 bit software? Is write speed improved?

[SSD]

Is there any benefits of using the 64 bit software? Is write speed improved?

 

With 64 bit software you get access to much more memory.

 

Raw performance does no increase, in fact you could argue is would decrease a tiny bit.

 

Disk performance is unaffected, although with more memory you get more caching and this may result in apparent better disk performance at times.

[Trunkz]

Not sure if I'm doing something wrong here, but I wanted to convert my array to xfs (from reiser). So I took a disk out of the array, formatted to xfs. Then placed the disk back in the array, then was given the option to rebuild the disk from the parity drive. 15hours later, the disk rebuild has completed however the data is not there. Does a disk rebuild not support different partition types?

[SSD]

Not sure if I'm doing something wrong here, but I wanted to convert my array to xfs (from reiser). So I took a disk out of the array, formatted to xfs. Then placed the disk back in the array, then was given the option to rebuild the disk from the parity drive. 15hours later, the disk rebuild has completed however the data is not there. Does a disk rebuild not support different partition types?

 

This has been discussed in this thread. There are no tools provided to convert from one filesystem to another. (See HERE).

 

Suggest you check out the link in my sig about what is parity. You would understand how what you attempted could not work. Parity will restore a partition sector by sector - NOT file by file.

 

What you may have done is found a bug. So you removed a disk from the array, formatted it as XFS, did a rebuld, and now the drive appears empty?

 

If so, please provide more of a play by play, including, for example, the exact command you used to format the disk. Was the disk in the array or outside the array when you formatted it? It would help LimeTech figure our how this happened to prevent it in the future. I would not do any writes to the array because you are in a very delicate state and at risk for losing everything on that disk!!!

[Trunkz]

Not sure if I'm doing something wrong here, but I wanted to convert my array to xfs (from reiser). So I took a disk out of the array, formatted to xfs. Then placed the disk back in the array, then was given the option to rebuild the disk from the parity drive. 15hours later, the disk rebuild has completed however the data is not there. Does a disk rebuild not support different partition types?

 

This has been discussed in this thread. There are no tools provided to convert from one filesystem to another.

 

Suggest you check out the link in my sig about what is parity. You would understand how what you attempted could not work. Parity will restore a partition sector by sector - NOT file by file.

 

What you may have done is found a bug. So you removed a disk from the array, formatted it as XFS, did a rebuld, and now the drive appears empty?

 

If so, please provide more of a play by play, including, for example, the exact command you used to format the disk. Was the disk in the array or outside the array when you formatted it? It would help LimeTech figure our how this happened to prevent it in the future. I would not do any writes to the array because you are in a very delicate state and at risk for losing everything on that disk!!!

Oh balls.. Okey here's what was done exactly:

 

1. Stopped array.

2. Clicked on Disk 1 (for example) & changed partition type from reiserfs to xfs. Pressed Apply then Done.

3. Back on main page, removed disk from array.

4. Mounted array & formatted to XFS.

5. Stopped array.

6. Mounted disk back to 'Disk 1' slot.

7. Started array, and began data disk rebuild.

 

What steps do I suggest I do to try and rectify this?

[dlandon]

Not sure if I'm doing something wrong here, but I wanted to convert my array to xfs (from reiser). So I took a disk out of the array, formatted to xfs. Then placed the disk back in the array, then was given the option to rebuild the disk from the parity drive. 15hours later, the disk rebuild has completed however the data is not there. Does a disk rebuild not support different partition types?

 

This has been discussed in this thread. There are no tools provided to convert from one filesystem to another. (See HERE).

 

Suggest you check out the link in my sig about what is parity. You would understand how what you attempted could not work. Parity will restore a partition sector by sector - NOT file by file.

 

What you may have done is found a bug. So you removed a disk from the array, formatted it as XFS, did a rebuld, and now the drive appears empty?

 

If so, please provide more of a play by play, including, for example, the exact command you used to format the disk. Was the disk in the array or outside the array when you formatted it? It would help LimeTech figure our how this happened to prevent it in the future. I would not do any writes to the array because you are in a very delicate state and at risk for losing everything on that disk!!!

 

You can't rebuild a disk to a different format.  I converted some ReiserFS disks to XFS and it empties the disk when it was formatted.  Parity is broken for that disk when the format is changed.  As stated earlier, you have to offload the data from a disk, change the format, then load the data back on.

[itimpi]

That is the wrong procedure!

 

After step 2, you should have simply restarted the array.  The disk would now show up as unformatted; its format as xfs; and the option to format unformatted disks would be available.  Pressing the format button would have formatted the disk as an empty XFS format disk.  This would have kept the parity intact so no need to do any sort of rebuild.

 

Note that this process destroys any data on the disks.  As has been mentioned there is no support for conversion of the disk from one format to another keeping its data intact.

[SSD]

The fact that you allowed unRAID to format the disk as XFS means that your rebuild did nothing. It simply rebuilt exactly what was there before, a freshly formatted XFS partition on top of an RFS partition that contained your data.

 

I believe you have one chance. That would be to run reiserfsck on the disk. It will tell you to run with the rebuild-tree option. Reiser will do its best to put Humpty Dumpty back together. In the best circumstance, it would be able to recover some of your data. The good news is that reiserfsck has been very effective at recovering from a variety of missteps, but this will be new territory.

 

I breathe a heavy sigh on these kinds of posts. The forums try very hard to protect everyone from data loss. This topic (changing file system) was discussed at least 2 times in this thread. How could you install a beta without reading the beta thread? Simply boggles my mind that anyone would be so careless with data they care about. 

 

Good luck.

 

 

[garycase]

...  boggles my mind that anyone would be so careless with data they care about. 

 

Hopefully, if this is indeed "... data they care about ...", there's a BACKUP of the data somewhere 

Backups are always important; but ESPECIALLY if you're going to "play around" with an unfamiliar system and try modifying the file structure with a Beta release !!

 

[archedraft]

...  boggles my mind that anyone would be so careless with data they care about. 

 

Hopefully, if this is indeed "... data they care about ...", there's a BACKUP of the data somewhere 

Backups are always important; but ESPECIALLY if you're going to "play around" with an unfamiliar system and try modifying the file structure with a Beta release !!

 

+1! Last month I was messing around with the beta and doing things that I probably shouldn't have been  , ending up losing an entire drive worth of data but luckily I listened to Gary's insistent backup posts (Thanks Gary for the wisdom) and just copied back the important data back to my unRAID server. Best part of loosing a complete drive worth of data is knowing that the important stuff can easily be recovered.

[Trunkz]

The fact that you allowed unRAID to format the disk as XFS means that your rebuild did nothing. It simply rebuilt exactly what was there before, a freshly formatted XFS partition on top of an RFS partition that contained your data.

 

I believe you have one chance. That would be to run reiserfsck on the disk. It will tell you to run with the rebuild-tree option. Reiser will do its best to put Humpty Dumpty back together. In the best circumstance, it would be able to recover some of your data. The good news is that reiserfsck has been very effective at recovering from a variety of missteps, but this will be new territory.

 

I breathe a heavy sigh on these kinds of posts. The forums try very hard to protect everyone from data loss. This topic (changing file system) was discussed at least 2 times in this thread. How could you install a beta without reading the beta thread? Simply boggles my mind that anyone would be so careless with data they care about. 

 

Good luck.

Its no biggy, thankfully by sheer luck that disk was new and didnt have much data on, so it'll just take a day or two to repopulate. Should really read a thread completely before attempting something unfamiliar next time. Thanks everyone!

[sane]

As has been mentioned there is no support for conversion of the disk from one format to another keeping its data intact.

Yeah, that's part of the reason I suggested that serious consideration be given to integrating FSTransform in there somehow, giving a way to transition from one FS to the other whilst maintaining parity, in place. However Lime aren't interested in that at the moment - which I can kind of understand.

 

I'm going to need an addition disk soon, and I plan to test out copying the entire contents of one drive to the new disk, running FSTransform over it, then bolting it in as part of the array (parity would of course need a rebuild). However I need at least a RC to do so; I'm not trusting a running system to a beta.

 

Still not sure if XFS or BTRFS is the way to go for data disks. If you're moving away from ReiserFS because you aren't sure of future support - is BTRFS likely to be longer lasting?

[SSD]

As has been mentioned there is no support for conversion of the disk from one format to another keeping its data intact.

Yeah, that's part of the reason I suggested that serious consideration be given to integrating FSTransform in there somehow, giving a way to transition from one FS to the other whilst maintaining parity, in place. However Lime aren't interested in that at the moment - which I can kind of understand.

 

I'm going to need an addition disk soon, and I plan to test out copying the entire contents of one drive to the new disk, running FSTransform over it, then bolting it in as part of the array (parity would of course need a rebuild). However I need at least a RC to do so; I'm not trusting a running system to a beta.

 

Still not sure if XFS or BTRFS is the way to go for data disks. If you're moving away from ReiserFS because you aren't sure of future support - is BTRFS likely to be longer lasting?

 

If the operation is done on the "md" device (e..g, /dev/md5), parity would be maintained through the transform.

[sane]

 

If the operation is done on the "md" device (e..g, /dev/md5), parity would be maintained through the transform.

Might be worth a try, although speed may end up being an issue. Got to get another disk and an RC version of UNRAID 6 first though....

[Brettv]

Has anything changed (since b5a) which would stop the fan_speed plugin working?

 

My fans appear to be running at full speed with no evidence of any control.

 

No.  Please post this in the new Defect Reports board.

http://lime-technology.com/forum/index.php?board=61.0

 

Okay, after some investigation, it would seem that this is not a defect, but definitely a change ...

 

I have had to amend the configuration of sensor/fan devices in the fan_speed plg file:

 

ARRAY_FAN=/sys/class/hwmon/hwmon1/device/pwm2

becomes

ARRAY_FAN=/sys/devices/platform/w83627ehf.2608/pwm2

 

and

 

ARRAY_FAN_INPUT=/sys/class/hwmon/hwmon1/device/fan2_input

becomes

ARRAY_FAN_INPUT=/sys/devices/platform/w83627ehf.2608/fan2_input

 

Since making these changes, fan speeds are being controlled again.

 

Obviously, these changes are specific to my own hardware configuration.  To assist with identifying what changes are required in your system, you can use the following commands:

find /sys -name pwm*
find /sys -name fan*

 

Thanks for this, I had the same issue on my system, followed your guidelines, modified my scripts and back to normal

 

Thanks

-Brett