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

 

Pleased to hear that it helped someone else!

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:

 

I can see why you thought this might work but parity is at the block level and knows nothing about files...

 

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.

You must of left out this step:

3a. Saw disk reported missing and clicked Start, thereby disabling that disk.

 

4. Mounted array & formatted to XFS.

This formats Disk 1 as XFS, deleting any data that was previously there.  Since this is a disabled disk, the actual disk was not formatted (because it's not there), but instead parity is updated to reflect the changes.

 

5. Stopped array.

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

7. Started array, and began data disk rebuild.

Now all you're doing is rebuilding current "Disk 1" onto the physical device you just assigned.  After rebuild this physical device now has the blank file system written to it that you built in step 4.

 

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

As you noticed all data is gone.  What you could have done is this:

 

4a. Find out linux device identifer of 'unassigned' disk1, let's say its 'sdd'.

Create a mount point, mount disk, copy all files to disk1, unmount:

mkdir /x

mount /dev/sdd1 /x

cp -rp /x/* /mnt/disk1

umount /x

 

Now you can pickup with step 5.

 

Make sense?

 

As you noticed all data is gone.  What you could have done is this:

 

4a. Find out linux device identifer of 'unassigned' disk1, let's say its 'sdd'.

Create a mount point, mount disk, copy all files to disk1, unmount:

mkdir /x

mount /dev/sdd1 /x

cp -rp /x/* /mnt/disk1

umount /x

 

Now you can pickup with step 5.

 

Make sense?

Nifty! So, theoretically, if your array is healthy and you are willing to take the risks of losing data if a drive fails during the process, you can do the format conversion without any extra drives, and without copying data in and out of the box.

 

Any possibility of an official step by step guide? Or even better, a command line script with some checks in place to keep people from crossing up potentially data erasing commands? Now that the procedure has been outlined in your post, I'm sure more people are going to try it.

Transmission eats the server's memory

 

Hello,

I'm using the latest version of the 6.0-beta7 unRIAD and it installed a number of plugins under docker. the plugins are: Couchpotato | HTPC-Manager | Transmission course. When a server at rest and reasonable memory is the use of 1289 from 6 GHz As shown in the first picture. When the transmission kicks (Download Movie) quickly ran out of memory, as shown in the second picture. I'd love to help and solve the problem.

 

To release the memory I'm using the following command.

 

sudo sysctl -w vm.drop_caches = 3

Noticed something very strange.

 

I was coping some large files from my cache disk to an array disk. It was going exceedingly slow - maybe 5-10 MB/sec. There was no other I/O on the array at that time. The only disks spinning were the cache, the target array disk (a fast disk), and the parity (also fast). I could not understand why it was so slow. On a whim I paused the copy and spun up all of the array disks. Immediately after resuming the copy, it started running hugely faster (see the screenshot below).

 

I am not running turbo mode (at least not on purpose).

 

Any idea why spinning up the array would speed up the copy so dramatically.

 

One more point, when monitoring the slow activity, it seemed that the reads from the cache were slow, but the writes were fast. I'd see the reading going along at 12 MB/sec and then get a bursted write at 60 MB/sec before the reads started again.

 

Note my copies are disk to disk, not using user shares.

Transmission eats the server's memory

 

Hello,

I'm using the latest version of the 6.0-beta7 unRIAD and it installed a number of plugins under docker. the plugins are: Couchpotato | HTPC-Manager | Transmission course. When a server at rest and reasonable memory is the use of 1289 from 6 GHz As shown in the first picture. When the transmission kicks (Download Movie) quickly ran out of memory, as shown in the second picture. I'd love to help and solve the problem.

 

what movie release.quality, 1:1 bluray rip? transmission eating up all your ram? it getting eaten up during unrar? etc.. i dont think this has anything to do with unraid specifically... but just configuration of apps.. prob best to hollar at cp/transmission once you know where the issue is...

Transmission eats the server's memory

 

Hello,

I'm using the latest version of the 6.0-beta7 unRIAD and it installed a number of plugins under docker. the plugins are: Couchpotato | HTPC-Manager | Transmission course. When a server at rest and reasonable memory is the use of 1289 from 6 GHz As shown in the first picture. When the transmission kicks (Download Movie) quickly ran out of memory, as shown in the second picture. I'd love to help and solve the problem.

 

Thanks for the answer.

 

I just download bluray movies, DTS quality. All downloaded some mkv movies without the need to unrar.

 

what movie release.quality, 1:1 bluray rip? transmission eating up all your ram? it getting eaten up during unrar? etc.. i dont think this has anything to do with unraid specifically... but just configuration of apps.. prob best to hollar at cp/transmission once you know where the issue is...

Transmission eats the server's memory

 

Unused memory is wasted memory. Read this site completely: http://www.linuxatemyram.com/

bug or normal expected behavior?

 

ok while i was away my home got one of these one in a 3 months power outages and my servers where not shutdown cleanly

 

yesterday i come back home see that beta 7 is release and since i did a parity check last week sunday i think ok since he is down now i take the flash drive and upgrade

he can start with beta 7 and do a parity check with beta7

 

but he didn't want to start the array

booted fine

but when i push start the array didn't start not even in maintenance mode

 

so changed 4 files back to beta6 and now he is running a parity check

guess can upgrade to beta 8 once he completed that LOL

 

just wanted to know if this is a bug or a sort of protection ?

 

 

bug or normal expected behavior?

 

ok while i was away my home got one of these one in a 3 months power outages and my servers where not shutdown cleanly

 

yesterday i come back home see that beta 7 is release and since i did a parity check last week sunday i think ok since he is down now i take the flash drive and upgrade

he can start with beta 7 and do a parity check with beta7

 

but he didn't want to start the array

booted fine

but when i push start the array didn't start not even in maintenance mode

 

so changed 4 files back to beta6 and now he is running a parity check

guess can upgrade to beta 8 once he completed that LOL

 

just wanted to know if this is a bug or a sort of protection ?

Can't explain it.  But if we had the system log from when you were click Start and nothing happened, then might be able to explain it.

oops here you go

 

this should be boot from beta 7...

2 start attempts ... 1 start attempt with maintenance

reboot

same start attempts

clean shutdown

syslog-20140901-093111.zip

It looks as if your key was not recognized?

 

It needs to be in the /boot/config folder.  Do you by any chance have it directly under /boot?

10 points an a kiss of the female actress of his choice for Itimpi

 

will wait for the parity check though .... :0

 

Tom Might need to add a error message for that .. would make things easier to spot

 

Tom Might need to add a error message for that .. would make things easier to spot

 

It's in the announcement post that you need to move keys from /boot to /boot/config.

 

So with beta8 there is facility to upgrade unraid os itself via plugin mechanism.  When next release is generated you update via webgui.  In addition to downloading the release zip file, unpacking and moving bzimage/bzroot/etc to the flash, we can have special purpose scripts to do other update-related tasks should they be necessary.

... we can have special purpose scripts to do other update-related tasks should they be necessary.

 

Will we be able to add our own personal scripts?  I always keep previous releases on my flash drive for a while so that it is easy to revert, eg bzrootb7, bzimageb7, etc., so it would be great if this could be automated.

... we can have special purpose scripts to do other update-related tasks should they be necessary.

 

Will we be able to add our own personal scripts?  I always keep previous releases on my flash drive for a while so that it is easy to revert, eg bzrootb7, bzimageb7, etc., so it would be great if this could be automated.

 

The script will preserve current release, something like this:

 

1. read /etc/unraid-version to get the current running version, say 6.0-beta8

2. create /boot/v6.0-beta8

3. move bzimage,bzroot,xen,readme.txt, etc, to /boot/v6.0-beta8

4. cp new bzimage,bzroot,xen,readme.txt, etc to /boot

 

 

What happens with our modified syslinux.cfg file? For my example , I added necessary settings to run KVM. Maybe you not touch that file?

What happens with our modified syslinux.cfg file? For my example , I added necessary settings to run KVM. Maybe you not touch that file?

I checked mine - it has not changed since beta 7

 

What happens with our modified syslinux.cfg file? For my example , I added necessary settings to run KVM. Maybe you not touch that file?

The syslinux and config directories are not ordinarily touched by an upgrade.

Thanks Tom, good to know , and a backup is always good to have if something's get over written ;-)

What happens with our modified syslinux.cfg file? For my example , I added necessary settings to run KVM. Maybe you not touch that file?

The syslinux and config directories are not ordinarily touched by an upgrade.

 

But backups of those still might be nice.  Not to mention the rest of /boot.  I take a full snapshot of /boot on every upgrade (or major change).  i happen to store it on my PC, but having generated onto flash (and zipped to save space?) wouldn't be such a bad idea.  Just a thought while you're at it.

Noticed something very strange.

 

I was coping some large files from my cache disk to an array disk. It was going exceedingly slow - maybe 5-10 MB/sec. There was no other I/O on the array at that time. The only disks spinning were the cache, the target array disk (a fast disk), and the parity (also fast). I could not understand why it was so slow. On a whim I paused the copy and spun up all of the array disks. Immediately after resuming the copy, it started running hugely faster (see the screenshot below).

 

I am not running turbo mode (at least not on purpose).

 

Any idea why spinning up the array would speed up the copy so dramatically.

 

One more point, when monitoring the slow activity, it seemed that the reads from the cache were slow, but the writes were fast. I'd see the reading going along at 12 MB/sec and then get a bursted write at 60 MB/sec before the reads started again.

 

Note my copies are disk to disk, not using user shares.

 

it appears you are copying this through a windows machine... 7 or 8? I have seen similar occurrences when doing that. In my testing I browse to whatever share i want a file from and then realize, oops, need to plug in gig-e to get a good speed, plug it in wait for the network to come online via plugged in ethernet and start the copy. 9/10 times its at wifi speed (3-10mb/s) even though im plugged in. Seems Win 7/8 holds on to the share via the connection it was originally browsed with.

 

If i plug in right away and then browse to the share it goes as fast as the hardware allows it, generally over 100MB/s.

I may have found a bug today, or perhaps I'm doing something wrong but I've done this before in 5.x and it worked fine.

 

I upgraded a 750gb disk to a 2tb disk last night.  I precleared the disk beforehand.  Added it to the array and it began to rebuild.  All the data from the old disk is there and accessible but the disk did not expand to reflect the bigger size.  It knows it's a 2tb disk but it's still limited to 750gb.  Curious if it was just an error in the gui, I tried copying enough data to take it over 750gb via the disk share and it says there is not enough space.  It seems that the auto expansion did not take place. I've attached a screen shot.

 

Am I doing something wrong?  Is there a way to expand the disk manually now?  If it's a bug, do you need any other info from my system?

 

I may have found a bug today, or perhaps I'm doing something wrong but I've done this before in 5.x and it worked fine.

 

I upgraded a 750gb disk to a 2tb disk last night.  I precleared the disk beforehand.  Added it to the array and it began to rebuild.  All the data from the old disk is there and accessible but the disk did not expand to reflect the bigger size.  It knows it's a 2tb disk but it's still limited to 750gb.  Curious if it was just an error in the gui, I tried copying enough data to take it over 750gb via the disk share and it says there is not enough space.  It seems that the auto expansion did not take place. I've attached a screen shot.

 

Am I doing something wrong?  Is there a way to expand the disk manually now?  If it's a bug, do you need any other info from my system?

 

The auto-expansion was (temporarily) disabled when the new file system support was added.    Tom noted that this will be re-instated with v6.0 final (not sure if he plans to do it before then or not).

 

... I believe if you revert to Beta 6 and boot it will do the auto-expansion, but I'm not certain.  You may have to remove/replace the new disk and let it rebuild again.