unRAID Server Release 4.7 "final" Available

Nightstalk3rs · January 29, 2011

Okay guys, I have a quick (stupid) question about an Advanced Format drive that I already have installed in my UnRAID Server.

I installed this drive a while back, probably close to a year ago, and I'm having trouble remembering if i installed it with the jumper originally or not. The jumper is on the drive currently so I'm thinking I must of formatted it with the jumper on it since it's not like I could have formatted it without the jumper initially and THEN put the jumper on because that would have forced me to reformat the drive (I think).

Anyway, the reason I'm asking is because when I go to the Settings page for that particular AF disk, it says that the Partition format is "MBR: unaligned" which I thought means "specifies an MBR-style partition table with partition 1 starting in sector 63" (unless that is just for new disks?). I'm probably just making this more confusing than it needs to be, but I guess I should simply ask if there is a way to determine which partition format that old AF drive is using to ensure that it is really on sector 64 and not 63. I'm thinking that because the jumper is place that it means it really is on sector 64, but I honestly am not sure and just wanted to ask before doing something crazy like copy the data to an empty drive and re-formatting it.

Thanks for your time!

Joe L. · January 29, 2011

Okay guys, I have a quick (stupid) question about an Advanced Format drive that I already have installed in my UnRAID Server.

I installed this drive a while back, probably close to a year ago, and I'm having trouble remembering if i installed it with the jumper originally or not. The jumper is on the drive currently so I'm thinking I must of formatted it with the jumper on it since it's not like I could have formatted it without the jumper initially and THEN put the jumper on because that would have forced me to reformat the drive (I think).

Anyway, the reason I'm asking is because when I go to the Settings page for that particular AF disk, it says that the Partition format is "MBR: unaligned" which I thought means "specifies an MBR-style partition table with partition 1 starting in sector 63" (unless that is just for new disks?). I'm probably just making this more confusing than it needs to be, but I guess I should simply ask if there is a way to determine which partition format that old AF drive is using to ensure that it is really on sector 64 and not 63. I'm thinking that because the jumper is place that it means it really is on sector 64, but I honestly am not sure and just wanted to ask before doing something crazy like copy the data to an empty drive and re-formatting it.

Thanks for your time!

The jumper electrically adds 1 to requested sectors. The drive is partitioned with a start on sector 63, which when accessed actually gets sector 64, which is aligned.

To see the current partitioning type:

fdisk -lu /dev/sdX

where sdX = the three letter device for your disk

You do not need to do anything if you have a jumper in place on that drive. Your disk is already working in its most efficient manner.

Joe L.

Nightstalk3rs · January 29, 2011

Thanks for the information as always Joe L.

I ran the fdisk utility on that drive and this is what it came up with

Disk /dev/sdb: 2000.3 GB, 2000398934016 bytes
1 heads, 63 sectors/track, 62016336 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000

  Device Boot      Start         End      Blocks   Id  System
/dev/sdb1              63  3907029167  1953514552+  83  Linux
Partition 1 does not end on cylinder boundary.

I noticed it says "63 sectors/track". Is that correct, or would it not report as 64 when the jumper is in place? I noticed you said the jumper electrically adds 1 to the sector so I'm thinking it still would be 64 then like you said. I'm just curious is all and want to make sure that I'm getting the most out of that drive

Thanks again!

Joe L. · January 29, 2011

Thanks for the information as always Joe L.

I ran the fdisk utility on that drive and this is what it came up with
Disk /dev/sdb: 2000.3 GB, 2000398934016 bytes
1 heads, 63 sectors/track, 62016336 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000

  Device Boot      Start         End      Blocks   Id  System
/dev/sdb1              63  3907029167  1953514552+  83  Linux
Partition 1 does not end on cylinder boundary.
I noticed it says "63 sectors/track". Is that correct, or would it not report as 64 when the jumper is in place? I noticed you said the jumper electrically adds 1 to the sector so I'm thinking it still would be 64 then like you said. I'm just curious is all and want to make sure that I'm getting the most out of that drive

Thanks again!

That is the disk reporting its "fake" geometry to be compatible with very old operating systems. ALL disks report 63 sectors per track, and they ALL lie. There has not been a constant number of sectors per track since the 80s.

There is no indication the jumper is in place, on any drive. The only way we know is to visually inspect the back of the drive.

Your first partition does START on sector 63, and ends on sector 3907029167. (and, because of the jumper on the drive, requests to that partition are translated to 64 through 3907029168 internally.)

Don't change anything. The jumpered disk is fine as it is.

Joe L.

dschock · January 29, 2011

Tom may want to have a look at this, because I don't believe he intended this to be a problem. The drive size calculation has been changed between v4.6 and v4.7, certainly because of the added support for 4k drives (Advanced Format), and as you can see from goinsnoopin's drive, is off by 4K, one AF sector. This drive was detected as a Seagate 320GB drive:

kernel: ata2.00: HPA detected: current 625140335, native 625142448

However, the v4.7 unRAID web page shows the drive size as 312570132, but claims it should be 312570136, which is probably what v4.6 calculated it as. I strongly suspect that Tom did not intend this to be a problem for so many. And I do believe there are quite a few users who have this problem, many like goinsnoopin who don't even know it yet, until they try to upgrade. Is it possible that the calculation can be tweaked in a v4.7.1, to avoid unnecessarily requiring this repair, for those with the Gigabyte HPA? It is easy to detect this exact situation, by detecting the native vs current sector count difference of 2113. I think I just heard Tom groaning!

Okay. I'm fairly new to unRaid but I've been testing serveral scenarios and playing with many of the unMenu packages with the free 3 disk version of 4.6 unRaid. I've just built a new server after researching hardware and am ready get started on a production server. I have purchased he pro version of unRaid. I've loaded 4.7 and the latest preclear script. I have 5 WD20EARS and I have installed screen. I have to say, I'm suffering from information overload.

My first question is will the above issue cause a problem for me ?

My second question is what should the "Disk settings" be in 4.7(i.e I'm guessing the Default partition format should be 4K-aligned)?

My next quesion is should my preclear simply be preclear_disk.sh -A /dev/sdX (where X is one of the drives)?

I appologize but I really am figure this out on my own before asking for help. I really want to get started but I want to do it right. I find myself going to many different places trying to ge the latest information. I'm getting worn out trying to keep it all straight.

If someone would be willing to get me going with the latest information I would appreciate it very much.

Thanks in advance.

dave

Joe L. · January 29, 2011

Tom may want to have a look at this, because I don't believe he intended this to be a problem. The drive size calculation has been changed between v4.6 and v4.7, certainly because of the added support for 4k drives (Advanced Format), and as you can see from goinsnoopin's drive, is off by 4K, one AF sector. This drive was detected as a Seagate 320GB drive:

kernel: ata2.00: HPA detected: current 625140335, native 625142448

However, the v4.7 unRAID web page shows the drive size as 312570132, but claims it should be 312570136, which is probably what v4.6 calculated it as. I strongly suspect that Tom did not intend this to be a problem for so many. And I do believe there are quite a few users who have this problem, many like goinsnoopin who don't even know it yet, until they try to upgrade. Is it possible that the calculation can be tweaked in a v4.7.1, to avoid unnecessarily requiring this repair, for those with the Gigabyte HPA? It is easy to detect this exact situation, by detecting the native vs current sector count difference of 2113. I think I just heard Tom groaning!

Okay. I'm fairly new to unRaid but I've been testing serveral scenarios and playing with many of the unMenu packages with the free 3 disk version of 4.6 unRaid. I've just built a new server after researching hardware and am ready get started on a production server. I have purchased he pro version of unRaid. I've loaded 4.7 and the latest preclear script. I have 5 WD20EARS and I have installed screen. I have to say, I'm suffering from information overload.

My first question is will the above issue cause a problem for me ?

It should not be. Do you have an older Gigabyte motherboard where the "feature" that copied the bios to a disk was not disabled by default?

You will probably want MBR-4k-aligned. You will NOT want to install any jumpers on your EARS drives. If you have installed jumpers, then you want MBR-4k-non-aligned, because the jumper will add 1 to sectors requested and end up as "aligned".

My second question is what should the "Disk settings" be in 4.7(i.e I'm guessing the Default partition format should be 4K-aligned)?

answerd already.

My next quesion is should my preclear simply be preclear_disk.sh -A /dev/sdX (where X is one of the drives)?

If there is NO jumber on the EARS drives, yes. If there is a jumper you installed, then do not use the "-A" option as it would only make the two in combination result in sector access not 4.k aligned.

I appologize but I really am figure this out on my own before asking for help. I really want to get started but I want to do it right. I find myself going to many different places trying to ge the latest information. I'm getting worn out trying to keep it all straight.

If someone would be willing to get me going with the latest information I would appreciate it very much.

Thanks in advance.

dave

Good luck. It is not as hard as it might seem. Also, I just uploaded the newest version of preclear_disk.sh within the past hour. If yours is not version 1.2, you have the older version. The older version would not list some drives as candidates for pre-clear on some disk controller when the "-l" option was used. It would still clear them, but those drives were not listed. Get the newer version of preclear_disk.sh.

If not sure, type:

preclear_disk.sh -v

It will print the version number.

Joe L.

dschock · January 29, 2011

Tom may want to have a look at this, because I don't believe he intended this to be a problem. The drive size calculation has been changed between v4.6 and v4.7, certainly because of the added support for 4k drives (Advanced Format), and as you can see from goinsnoopin's drive, is off by 4K, one AF sector. This drive was detected as a Seagate 320GB drive:

kernel: ata2.00: HPA detected: current 625140335, native 625142448

However, the v4.7 unRAID web page shows the drive size as 312570132, but claims it should be 312570136, which is probably what v4.6 calculated it as. I strongly suspect that Tom did not intend this to be a problem for so many. And I do believe there are quite a few users who have this problem, many like goinsnoopin who don't even know it yet, until they try to upgrade. Is it possible that the calculation can be tweaked in a v4.7.1, to avoid unnecessarily requiring this repair, for those with the Gigabyte HPA? It is easy to detect this exact situation, by detecting the native vs current sector count difference of 2113. I think I just heard Tom groaning!

Okay. I'm fairly new to unRaid but I've been testing serveral scenarios and playing with many of the unMenu packages with the free 3 disk version of 4.6 unRaid. I've just built a new server after researching hardware and am ready get started on a production server. I have purchased he pro version of unRaid. I've loaded 4.7 and the latest preclear script. I have 5 WD20EARS and I have installed screen. I have to say, I'm suffering from information overload.

My first question is will the above issue cause a problem for me ?

It should not be. Do you have an older Gigabyte motherboard where the "feature" that copied the bios to a disk was not disabled by default?

You will probably want MBR-4k-aligned. You will NOT want to install any jumpers on your EARS drives. If you have installed jumpers, then you want MBR-4k-non-aligned, because the jumper will add 1 to sectors requested and end up as "aligned".

My second question is what should the "Disk settings" be in 4.7(i.e I'm guessing the Default partition format should be 4K-aligned)?
answerd already.

My next quesion is should my preclear simply be preclear_disk.sh -A /dev/sdX (where X is one of the drives)?

If there is NO jumber on the EARS drives, yes. If there is a jumper you installed, then do not use the "-A" option as it would only make the two in combination result in sector access not 4.k aligned.

I appologize but I really am figure this out on my own before asking for help. I really want to get started but I want to do it right. I find myself going to many different places trying to ge the latest information. I'm getting worn out trying to keep it all straight.

If someone would be willing to get me going with the latest information I would appreciate it very much.

Thanks in advance.

dave

Good luck. It is not as hard as it might seem. Also, I just uploaded the newest version of preclear_disk.sh within the past hour. If yours is not version 1.2, you have the older version. The older version would not list some drives as candidates for pre-clear on some disk controller when the "-l" option was used. It would still clear them, but those drives were not listed. Get the newer version of preclear_disk.sh.

If not sure, type:

preclear_disk.sh -v

It will print the version number.

Joe L.

Thanks for your quick reply Joe.

I do have a Gigabyte board but the 'copy bios to disk' is disabled by default.

No jumpers on the EARS so I will use MBR 4k-aligned and -A on the preclear script (I just grabbed the latest thanks).

Thanks for the help Joe. I really appreciate one of the experts letting me know I'm on the right track.

dave

Nightstalk3rs · January 29, 2011

Thanks for the information as always Joe L.

I ran the fdisk utility on that drive and this is what it came up with
Disk /dev/sdb: 2000.3 GB, 2000398934016 bytes
1 heads, 63 sectors/track, 62016336 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000

  Device Boot      Start         End      Blocks   Id  System
/dev/sdb1              63  3907029167  1953514552+  83  Linux
Partition 1 does not end on cylinder boundary.
I noticed it says "63 sectors/track". Is that correct, or would it not report as 64 when the jumper is in place? I noticed you said the jumper electrically adds 1 to the sector so I'm thinking it still would be 64 then like you said. I'm just curious is all and want to make sure that I'm getting the most out of that drive

Thanks again!
That is the disk reporting its "fake" geometry to be compatible with very old operating systems. ALL disks report 63 sectors per track, and they ALL lie. There has not been a constant number of sectors per track since the 80s.

There is no indication the jumper is in place, on any drive. The only way we know is to visually inspect the back of the drive.

Your first partition does START on sector 63, and ends on sector 3907029167. (and, because of the jumper on the drive, requests to that partition are translated to 64 through 3907029168 internally.)

Don't change anything. The jumpered disk is fine as it is.

Joe L.

Thanks Joe! I appreciate the help with everything and explaining the specifics for me

The server has been running fine as well since adding two new 2TB WD green drives without the jumpers. I used the new Preclear script with the "-A" option on both drives at the same time and they cleared in just over a day.

Thanks again for your help and everything else!

Simon · January 30, 2011

Using 4.7, I replaced a 1TB WD Black (EADS) drive with a 2TB WD EARS without a jumper but pre-cleared with -A. The rebuild has just completed and all the balls are green now. One oddity though - if I click on the disk from the array screen it says the File system type is Unknown. I haven't rebooted since I rebuilt it, so I don't know if next time it comes up whether it will read reiserfs. Is the expected behaviour?

Joe L. · January 30, 2011

Using 4.7, I replaced a 1TB WD Black (EADS) drive with a 2TB WD EARS without a jumper but pre-cleared with -A. The rebuild has just completed and all the balls are green now. One oddity though - if I click on the disk from the array screen it says the File system type is Unknown. I haven't rebooted since I rebuilt it, so I don't know if next time it comes up whether it will read reiserfs. Is the expected behaviour?

Expected Yes... A Bug, yes... Reported in the past, Yes. It will show the file-system type when you next reboot.

limetech · January 30, 2011

Using 4.7, I replaced a 1TB WD Black (EADS) drive with a 2TB WD EARS without a jumper but pre-cleared with -A. The rebuild has just completed and all the balls are green now. One oddity though - if I click on the disk from the array screen it says the File system type is Unknown. I haven't rebooted since I rebuilt it, so I don't know if next time it comes up whether it will read reiserfs. Is the expected behaviour?

Expected Yes... A Bug, yes... Reported in the past, Yes. It will show the file-system type when you next reboot.

Expected? No... A Bug? Appears so... Reported in the past? Yes... Fixed in the past, Yes... New in 4.7? Appears to be the case... Will it be correct when you next reboot? Yes... Does it warrant a 4.7.1 release? Probably not.

Simon · January 30, 2011

Thanks guys. Just rebooted so we could close the loop on this, and I can confirm it does indeed show reiserfs now.

Joe L. · January 30, 2011

Using 4.7, I replaced a 1TB WD Black (EADS) drive with a 2TB WD EARS without a jumper but pre-cleared with -A. The rebuild has just completed and all the balls are green now. One oddity though - if I click on the disk from the array screen it says the File system type is Unknown. I haven't rebooted since I rebuilt it, so I don't know if next time it comes up whether it will read reiserfs. Is the expected behaviour?

Expected Yes... A Bug, yes... Reported in the past, Yes. It will show the file-system type when you next reboot.

Expected? No... A Bug? Appears so... Reported in the past? Yes... Fixed in the past, Yes... New in 4.7? Appears to be the case... Will it be correct when you next reboot? Yes... Does it warrant a 4.7.1 release? Probably not.

It might be you fixed it when initially adding a new disk to the array, but not when re-constructing a missing/un-assigned drive.

End-users are really good at finding the subtle things... aren't they.

Joe L.

loadme · January 30, 2011

Upgraded to 4.7 today.

As for the AF drives, did I understood everything right?

All existing drives

--> no matter what kind: don't touch

New drives without AF

--> preclear as usual, no need for new settings anywhere

New drives with AF

--> either preclear script with the -A parameter, or setting the new unraid

device setting to "MBR: 4K-aligned", before using the unraid formatting.

once the formatting is done, i can change it back (?)

New WD Ears drives

--> no setting or parameter needed, if the jumper is set. if the jumper isnt set,

use it like "New drives with AF"

and overall: I can set up the "MBR: 4K-aligned" setting, because it wont hurt

for unraid 4.7++, but those drives arent compatible to older versions

did i get anything wrong?

Joe L. · January 30, 2011

Upgraded to 4.7 today.

As for the AF drives, did I understood everything right?

All existing drives

--> no matter what kind: don't touch

If they are working now, best bet is to not mess with them.

New drives without AF

--> preclear as usual, no need for new settings anywhere

As soon as you have ANY drive partitioned for 4k alignment you can no longer revert to the 4.6 release or prior. (well, you might, but it will not be easy as you would have to re-partition and move the entire partitions data. Easiest to say you cannot revert.)

For that reason, you might as well just set the MBR-4k-align setting and leave it set and use it for all newly added drives. A drive aligned at a 4096 byte boundary is automatically aligned on a 512 byte boundary (the prior standard).

New drives with AF

--> either preclear script with the -A parameter, or setting the new unraid

device setting to "MBR: 4K-aligned", before using the unraid formatting.

yes

once the formatting is done, i can change it back (?)

You can changes the setting but it does not affect drives already partitioned.

New WD Ears drives

--> no setting or parameter needed, if the jumper is set.

If the jumper is set, you want MBR-unaligned, or preclear without the "-A" option, or with the "-a" (lower case) option. The lower case "-a" option requests the partition start on sector 63 as it always has in unRAID 4.6 and prior. It is the same as "MBR-unaligned". It is at this time (in version 1.2 of the preclear script and prior) the default, so if you do not specify "-A" you get the default partition starting on sector 63.

if the jumper isn't set,
use it like "New drives with AF"

Yes.

and overall: I can set up the "MBR: 4K-aligned" setting, because it wont hurt

for unraid 4.7++, but those drives arent compatible to older versions

Yes.

did i get anything wrong?

I don't think so.

Lou · January 30, 2011

Hi Could someone tell me what these errors are just started to show upgraded from 4.6 to 4.7 still showing up nothing new added or changed thanks.

Lou

Jan 29 21:56:54 Unraid ntpd[1488]: synchronized to 208.97.105.139, stratum 3
Jan 29 21:58:28 Unraid kernel: ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x1800000 action 0x0 frozen
Jan 29 21:58:28 Unraid kernel: ata4.01: SError: { LinkSeq TrStaTrns }
Jan 29 21:58:28 Unraid kernel: ata4.01: failed command: READ DMA EXT
Jan 29 21:58:28 Unraid kernel: ata4.01: cmd 25/00:08:af:d1:f6/00:00:2e:00:00/f0 tag 0 dma 4096 in
Jan 29 21:58:28 Unraid kernel:          res 40/00:ff:00:00:00/00:00:00:00:00/10 Emask 0x4 (timeout)
Jan 29 21:58:28 Unraid kernel: ata4.01: status: { DRDY }
Jan 29 21:58:28 Unraid kernel: ata4.00: hard resetting link
Jan 29 21:58:28 Unraid kernel: ata4.01: hard resetting link
Jan 29 21:58:29 Unraid kernel: ata4.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Jan 29 21:58:29 Unraid kernel: ata4.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Jan 29 21:58:29 Unraid kernel: ata4.00: configured for UDMA/133
Jan 29 21:58:29 Unraid kernel: ata4.01: configured for UDMA/133
Jan 29 21:58:29 Unraid kernel: ata4.01: device reported invalid CHS sector 0
Jan 29 21:58:29 Unraid kernel: ata4: EH complete
Jan 29 22:23:21 Unraid kernel: ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x800000 action 0x0 frozen
Jan 29 22:23:21 Unraid kernel: ata4.01: SError: { LinkSeq }
Jan 29 22:23:21 Unraid kernel: ata4.01: failed command: CHECK POWER MODE
Jan 29 22:23:21 Unraid kernel: ata4.01: cmd e5/00:00:00:00:00/00:00:00:00:00/10 tag 0
Jan 29 22:23:21 Unraid kernel:          res 40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Jan 29 22:23:21 Unraid kernel: ata4.01: status: { DRDY }
Jan 29 22:23:21 Unraid kernel: ata4.00: hard resetting link
Jan 29 22:23:22 Unraid kernel: ata4.01: hard resetting link
Jan 29 22:23:22 Unraid kernel: ata4.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Jan 29 22:23:22 Unraid kernel: ata4.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Jan 29 22:23:22 Unraid kernel: ata4.00: configured for UDMA/133
Jan 29 22:23:22 Unraid kernel: ata4.01: configured for UDMA/133
Jan 29 22:23:22 Unraid kernel: ata4: EH complete
Jan 29 22:28:33 Unraid kernel: mdcmd (20): spindown 0
Jan 29 22:28:34 Unraid kernel: mdcmd (21): spindown 3
Jan 29 22:30:25 Unraid kernel: mdcmd (22): spindown 1
Jan 29 22:30:26 Unraid kernel: mdcmd (23): spindown 2
Jan 29 22:33:07 Unraid kernel: mdcmd (24): spindown 4
Jan 29 22:33:08 Unraid kernel: mdcmd (25): spindown 5
Jan 29 22:33:09 Unraid kernel: mdcmd (26): spindown 6
Jan 29 22:35:00 Unraid emhttp: shcmd (40): /usr/sbin/hdparm -y /dev/sdi >/dev/null
Jan 30 00:06:02 Unraid kernel: mdcmd (27): spindown 4
Jan 30 00:06:03 Unraid kernel: mdcmd (28): spindown 5
Jan 30 00:06:04 Unraid kernel: mdcmd (29): spindown 6
Jan 30 00:07:16 Unraid kernel: ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x1800000 action 0x0 frozen
Jan 30 00:07:16 Unraid kernel: ata4.01: SError: { LinkSeq TrStaTrns }
Jan 30 00:07:16 Unraid kernel: ata4.01: failed command: READ DMA EXT
Jan 30 00:07:16 Unraid kernel: ata4.01: cmd 25/00:08:0f:a9:f7/00:00:58:00:00/f0 tag 0 dma 4096 in
Jan 30 00:07:16 Unraid kernel:          res 40/00:ff:00:00:00/00:00:00:00:00/10 Emask 0x4 (timeout)
Jan 30 00:07:16 Unraid kernel: ata4.01: status: { DRDY }
Jan 30 00:07:16 Unraid kernel: ata4.00: hard resetting link
Jan 30 00:07:16 Unraid kernel: ata4.01: hard resetting link
Jan 30 00:07:17 Unraid kernel: ata4.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Jan 30 00:07:17 Unraid kernel: ata4.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Jan 30 00:07:17 Unraid kernel: ata4.00: configured for UDMA/133
Jan 30 00:07:17 Unraid kernel: ata4.01: configured for UDMA/133
Jan 30 00:07:17 Unraid kernel: ata4.01: device reported invalid CHS sector 0
Jan 30 00:07:17 Unraid kernel: ata4: EH complete
Jan 30 00:39:04 Unraid kernel: mdcmd (30): spindown 0
Jan 30 00:39:04 Unraid kernel: mdcmd (31): spindown 1
Jan 30 00:39:05 Unraid kernel: mdcmd (32): spindown 2
Jan 30 00:39:06 Unraid kernel: mdcmd (33): spindown 3
Jan 30 00:39:07 Unraid kernel: mdcmd (34): spindown 4
Jan 30 00:39:08 Unraid kernel: mdcmd (35): spindown 5
Jan 30 00:39:09 Unraid kernel: mdcmd (36): spindown 6
Jan 30 00:47:02 Unraid sSMTP[8277]: Sent mail for [email protected] (221 fipsb01.cogeco.net) uid=0 username=root outbytes=653
Jan 30 03:40:01 Unraid logger: mover started
Jan 30 03:40:01 Unraid logger: ./Media/Movies/Standarddef Movies/Secretariat/Secretariat.avi
Jan 30 03:40:01 Unraid logger: .d..t...... ./
Jan 30 03:40:07 Unraid logger: .d..t...... Media/
Jan 30 03:40:07 Unraid logger: .d..t...... Media/Movies/
Jan 30 03:40:07 Unraid logger: .d..t...... Media/Movies/Standarddef Movies/
Jan 30 03:40:07 Unraid logger: cd+++++++++ Media/Movies/Standarddef Movies/Secretariat/
Jan 30 03:40:07 Unraid logger: >f+++++++++ Media/Movies/Standarddef Movies/Secretariat/Secretariat.avi
Jan 30 03:40:44 Unraid logger: ./Media/Movies/Standarddef Movies/Secretariat
Jan 30 03:40:44 Unraid logger: .d..t...... Media/Movies/Standarddef Movies/Secretariat/
Jan 30 03:40:44 Unraid logger: ./Media/Movies/Standarddef Movies/Adventures of power/Adventures of power.avi
Jan 30 03:40:44 Unraid logger: .d..t...... Media/Movies/Standarddef Movies/
Jan 30 03:40:44 Unraid logger: cd+++++++++ Media/Movies/Standarddef Movies/Adventures of power/
Jan 30 03:40:44 Unraid logger: >f+++++++++ Media/Movies/Standarddef Movies/Adventures of power/Adventures of power.avi
Jan 30 03:41:17 Unraid logger: ./Media/Movies/Standarddef Movies/Adventures of power
Jan 30 03:41:17 Unraid logger: .d..t...... Media/Movies/Standarddef Movies/Adventures of power/
Jan 30 03:41:17 Unraid logger: ./Media/Movies/Standarddef Movies
Jan 30 03:41:17 Unraid logger: .d..t...... Media/Movies/Standarddef Movies/
Jan 30 03:41:17 Unraid logger: ./Media/Movies
Jan 30 03:41:17 Unraid logger: .d..t...... Media/Movies/
Jan 30 03:41:17 Unraid logger: ./Media
Jan 30 03:41:17 Unraid logger: .d..t...... Media/
Jan 30 03:41:17 Unraid logger: .
Jan 30 03:41:32 Unraid logger: mover finished
Jan 30 04:11:39 Unraid kernel: mdcmd (37): spindown 0
Jan 30 04:11:40 Unraid kernel: mdcmd (38): spindown 1
Jan 30 04:11:41 Unraid kernel: mdcmd (39): spindown 2
Jan 30 04:11:42 Unraid kernel: mdcmd (40): spindown 3
Jan 30 04:11:42 Unraid kernel: mdcmd (41): spindown 4
Jan 30 04:11:43 Unraid kernel: mdcmd (42): spindown 5
Jan 30 04:11:44 Unraid kernel: mdcmd (43): spindown 6
Jan 30 04:11:46 Unraid emhttp: shcmd (41): /usr/sbin/hdparm -y /dev/sdi >/dev/null
Jan 30 05:43:12 Unraid kernel: ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x800000 action 0x0 frozen
Jan 30 05:43:12 Unraid kernel: ata4.01: SError: { LinkSeq }
Jan 30 05:43:12 Unraid kernel: ata4.01: failed command: CHECK POWER MODE
Jan 30 05:43:12 Unraid kernel: ata4.01: cmd e5/00:00:00:00:00/00:00:00:00:00/10 tag 0
Jan 30 05:43:12 Unraid kernel:          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Jan 30 05:43:12 Unraid kernel: ata4.01: status: { DRDY }
Jan 30 05:43:12 Unraid kernel: ata4.00: hard resetting link
Jan 30 05:43:12 Unraid kernel: ata4.01: hard resetting link
Jan 30 05:43:13 Unraid kernel: ata4.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Jan 30 05:43:13 Unraid kernel: ata4.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Jan 30 05:43:13 Unraid kernel: ata4.00: configured for UDMA/133
Jan 30 05:43:13 Unraid kernel: ata4.01: configured for UDMA/133
Jan 30 05:43:13 Unraid kernel: ata4: EH complete
Jan 30 06:20:09 Unraid kernel: ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x800000 action 0x0 frozen
Jan 30 06:20:09 Unraid kernel: ata4.01: SError: { LinkSeq }
Jan 30 06:20:09 Unraid kernel: ata4.01: failed command: CHECK POWER MODE
Jan 30 06:20:09 Unraid kernel: ata4.01: cmd e5/00:00:00:00:00/00:00:00:00:00/50 tag 0
Jan 30 06:20:09 Unraid kernel:          res 40/00:00:00:00:00/00:00:00:00:00/10 Emask 0x4 (timeout)
Jan 30 06:20:09 Unraid kernel: ata4.01: status: { DRDY }
Jan 30 06:20:09 Unraid kernel: ata4.00: hard resetting link
Jan 30 06:20:09 Unraid kernel: ata4.01: hard resetting link
Jan 30 06:20:10 Unraid kernel: ata4.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Jan 30 06:20:10 Unraid kernel: ata4.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Jan 30 06:20:10 Unraid kernel: ata4.00: configured for UDMA/133
Jan 30 06:20:10 Unraid kernel: ata4.01: configured for UDMA/133
Jan 30 06:20:10 Unraid kernel: ata4: EH complete

squirrellydw · January 30, 2011

Just upgraded to 4.7 from 4.5. Working great, thanks.

Simon · January 30, 2011

Another minor oddity in my system. I just tried to access my NFS shares for the first time since I upgraded to 4.7 and noticed that none of them had been exported. /etc/exports was empty. Going to the Shares screen and hitting apply for a share, it was immediately added to /etc/exports and normal service was resumed - nothing else required. Anyone else seeing this?

SSD · January 30, 2011

New drives with AF

--> either preclear script with the -A parameter, or setting the new unraid

device setting to "MBR: 4K-aligned", before using the unraid formatting.

once the formatting is done, i can change it back (?)

You cannot change the partitioning after the formatting is done.

You can't even change it after you've added it to your array and started the array (i.e., before formatting).

But you CAN change the partitioning of a precleared disk before you add it to your array. So if you forgot to add the -A option and precleared a disk, you can very quickly change the partitioning to be 4K aligned. Or if you have a spare disk (in or out of the closet ) you precleared a while ago, you can quickly change its partitioning. (But to reiterate, you can only do this before you add it to the array. This also does NOT allow someone to change the jumper and quickly change the partitioning. Although technically possible, Joe L. would need to enhance preclear to do this.)

olympia · January 30, 2011

Another minor oddity in my system. I just tried to access my NFS shares for the first time since I upgraded to 4.7 and noticed that none of them had been exported. /etc/exports was empty. Going to the Shares screen and hitting apply for a share, it was immediately added to /etc/exports and normal service was resumed - nothing else required. Anyone else seeing this?

see the release notes here:

http://lime-technology.com/forum/index.php?topic=9282.0

Simon · January 30, 2011

see the release notes here:

http://lime-technology.com/forum/index.php?topic=9282.0

Thank you! This was a 4.6 -> 4.7 upgrade, so maybe this should be in the 4.7 Release Notes too (?)... I did check those first!

Edit: Thinking about it, it's quite possible that I didn't use the NFS shares between upgrading to 4.6 and now, so I just didn't notice.

goinsnoopin · January 31, 2011

You must have had the drive on the other motherboard. It cannot come from the supermicro.

Go ahead, run the hdparm command ( on /dev/sdb )

Stop the array first

Then run

hdparm -N p625142448 /dev/sdb

You can see if it took with

hdparm -N /dev/sdb

Then, start the array and let it rebuild the disk onto itself.

Joe L.

Joe,

Thanks for the help! I made the changes you suggested, rebuilt the data, ran a parity check afterwards, upgraded to 4.7...no issues this time and ran another successful parity check. I checked the syslog and I no longer see any reference to hpa so I think I am all set and am off to replace my parity drive with a 2TB WD EARS.

Thanks again!

Dan

Ostrich · February 1, 2011

Has the AMD powernow drivers been included in this release?

They were included in an early 4.6 beta, but then i thought they were taken out and cant locate anything about them being re-included in the changelog, or on the project plan for development of unRaid?

Thanks

Ost.

BRiT · February 1, 2011

No. They remain removed. You'll have to look towards the 5.0 beta 3 release for any kernel driver changes.

RobJ · February 1, 2011

Hi Could someone tell me what these errors are just started to show upgraded from 4.6 to 4.7 still showing up nothing new added or changed thanks.

Lou

Jan 29 21:56:54 Unraid ntpd[1488]: synchronized to 208.97.105.139, stratum 3
Jan 29 21:58:28 Unraid kernel: ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x1800000 action 0x0 frozen
Jan 29 21:58:28 Unraid kernel: ata4.01: SError: { LinkSeq TrStaTrns }
Jan 29 21:58:28 Unraid kernel: ata4.01: failed command: READ DMA EXT
Jan 29 21:58:28 Unraid kernel: ata4.01: cmd 25/00:08:af:d1:f6/00:00:2e:00:00/f0 tag 0 dma 4096 in
Jan 29 21:58:28 Unraid kernel:          res 40/00:ff:00:00:00/00:00:00:00:00/10 Emask 0x4 (timeout)
Jan 29 21:58:28 Unraid kernel: ata4.01: status: { DRDY }
Jan 29 21:58:28 Unraid kernel: ata4.00: hard resetting link
Jan 29 21:58:28 Unraid kernel: ata4.01: hard resetting link
Jan 29 21:58:29 Unraid kernel: ata4.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Jan 29 21:58:29 Unraid kernel: ata4.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Jan 29 21:58:29 Unraid kernel: ata4.00: configured for UDMA/133
Jan 29 21:58:29 Unraid kernel: ata4.01: configured for UDMA/133
Jan 29 21:58:29 Unraid kernel: ata4.01: device reported invalid CHS sector 0
Jan 29 21:58:29 Unraid kernel: ata4: EH complete
Jan 29 22:23:21 Unraid kernel: ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x800000 action 0x0 frozen
Jan 29 22:23:21 Unraid kernel: ata4.01: SError: { LinkSeq }
Jan 29 22:23:21 Unraid kernel: ata4.01: failed command: CHECK POWER MODE
Jan 29 22:23:21 Unraid kernel: ata4.01: cmd e5/00:00:00:00:00/00:00:00:00:00/10 tag 0
Jan 29 22:23:21 Unraid kernel:          res 40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Jan 29 22:23:21 Unraid kernel: ata4.01: status: { DRDY }
Jan 29 22:23:21 Unraid kernel: ata4.00: hard resetting link
Jan 29 22:23:22 Unraid kernel: ata4.01: hard resetting link
Jan 29 22:23:22 Unraid kernel: ata4.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Jan 29 22:23:22 Unraid kernel: ata4.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Jan 29 22:23:22 Unraid kernel: ata4.00: configured for UDMA/133
Jan 29 22:23:22 Unraid kernel: ata4.01: configured for UDMA/133
Jan 29 22:23:22 Unraid kernel: ata4: EH complete
Jan 29 22:28:33 Unraid kernel: mdcmd (20): spindown 0
Jan 29 22:28:34 Unraid kernel: mdcmd (21): spindown 3
Jan 29 22:30:25 Unraid kernel: mdcmd (22): spindown 1
Jan 29 22:30:26 Unraid kernel: mdcmd (23): spindown 2
Jan 29 22:33:07 Unraid kernel: mdcmd (24): spindown 4
Jan 29 22:33:08 Unraid kernel: mdcmd (25): spindown 5
Jan 29 22:33:09 Unraid kernel: mdcmd (26): spindown 6
Jan 29 22:35:00 Unraid emhttp: shcmd (40): /usr/sbin/hdparm -y /dev/sdi >/dev/null
Jan 30 00:06:02 Unraid kernel: mdcmd (27): spindown 4
Jan 30 00:06:03 Unraid kernel: mdcmd (28): spindown 5
Jan 30 00:06:04 Unraid kernel: mdcmd (29): spindown 6
Jan 30 00:07:16 Unraid kernel: ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x1800000 action 0x0 frozen
Jan 30 00:07:16 Unraid kernel: ata4.01: SError: { LinkSeq TrStaTrns }
Jan 30 00:07:16 Unraid kernel: ata4.01: failed command: READ DMA EXT
Jan 30 00:07:16 Unraid kernel: ata4.01: cmd 25/00:08:0f:a9:f7/00:00:58:00:00/f0 tag 0 dma 4096 in
Jan 30 00:07:16 Unraid kernel:          res 40/00:ff:00:00:00/00:00:00:00:00/10 Emask 0x4 (timeout)
Jan 30 00:07:16 Unraid kernel: ata4.01: status: { DRDY }
Jan 30 00:07:16 Unraid kernel: ata4.00: hard resetting link
Jan 30 00:07:16 Unraid kernel: ata4.01: hard resetting link
Jan 30 00:07:17 Unraid kernel: ata4.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Jan 30 00:07:17 Unraid kernel: ata4.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Jan 30 00:07:17 Unraid kernel: ata4.00: configured for UDMA/133
Jan 30 00:07:17 Unraid kernel: ata4.01: configured for UDMA/133
Jan 30 00:07:17 Unraid kernel: ata4.01: device reported invalid CHS sector 0
Jan 30 00:07:17 Unraid kernel: ata4: EH complete
Jan 30 00:39:04 Unraid kernel: mdcmd (30): spindown 0
Jan 30 00:39:04 Unraid kernel: mdcmd (31): spindown 1
Jan 30 00:39:05 Unraid kernel: mdcmd (32): spindown 2
Jan 30 00:39:06 Unraid kernel: mdcmd (33): spindown 3
Jan 30 00:39:07 Unraid kernel: mdcmd (34): spindown 4
Jan 30 00:39:08 Unraid kernel: mdcmd (35): spindown 5
Jan 30 00:39:09 Unraid kernel: mdcmd (36): spindown 6
Jan 30 00:47:02 Unraid sSMTP[8277]: Sent mail for [email protected] (221 fipsb01.cogeco.net) uid=0 username=root outbytes=653
Jan 30 03:40:01 Unraid logger: mover started
Jan 30 03:40:01 Unraid logger: ./Media/Movies/Standarddef Movies/Secretariat/Secretariat.avi
Jan 30 03:40:01 Unraid logger: .d..t...... ./
Jan 30 03:40:07 Unraid logger: .d..t...... Media/
Jan 30 03:40:07 Unraid logger: .d..t...... Media/Movies/
Jan 30 03:40:07 Unraid logger: .d..t...... Media/Movies/Standarddef Movies/
Jan 30 03:40:07 Unraid logger: cd+++++++++ Media/Movies/Standarddef Movies/Secretariat/
Jan 30 03:40:07 Unraid logger: >f+++++++++ Media/Movies/Standarddef Movies/Secretariat/Secretariat.avi
Jan 30 03:40:44 Unraid logger: ./Media/Movies/Standarddef Movies/Secretariat
Jan 30 03:40:44 Unraid logger: .d..t...... Media/Movies/Standarddef Movies/Secretariat/
Jan 30 03:40:44 Unraid logger: ./Media/Movies/Standarddef Movies/Adventures of power/Adventures of power.avi
Jan 30 03:40:44 Unraid logger: .d..t...... Media/Movies/Standarddef Movies/
Jan 30 03:40:44 Unraid logger: cd+++++++++ Media/Movies/Standarddef Movies/Adventures of power/
Jan 30 03:40:44 Unraid logger: >f+++++++++ Media/Movies/Standarddef Movies/Adventures of power/Adventures of power.avi
Jan 30 03:41:17 Unraid logger: ./Media/Movies/Standarddef Movies/Adventures of power
Jan 30 03:41:17 Unraid logger: .d..t...... Media/Movies/Standarddef Movies/Adventures of power/
Jan 30 03:41:17 Unraid logger: ./Media/Movies/Standarddef Movies
Jan 30 03:41:17 Unraid logger: .d..t...... Media/Movies/Standarddef Movies/
Jan 30 03:41:17 Unraid logger: ./Media/Movies
Jan 30 03:41:17 Unraid logger: .d..t...... Media/Movies/
Jan 30 03:41:17 Unraid logger: ./Media
Jan 30 03:41:17 Unraid logger: .d..t...... Media/
Jan 30 03:41:17 Unraid logger: .
Jan 30 03:41:32 Unraid logger: mover finished
Jan 30 04:11:39 Unraid kernel: mdcmd (37): spindown 0
Jan 30 04:11:40 Unraid kernel: mdcmd (38): spindown 1
Jan 30 04:11:41 Unraid kernel: mdcmd (39): spindown 2
Jan 30 04:11:42 Unraid kernel: mdcmd (40): spindown 3
Jan 30 04:11:42 Unraid kernel: mdcmd (41): spindown 4
Jan 30 04:11:43 Unraid kernel: mdcmd (42): spindown 5
Jan 30 04:11:44 Unraid kernel: mdcmd (43): spindown 6
Jan 30 04:11:46 Unraid emhttp: shcmd (41): /usr/sbin/hdparm -y /dev/sdi >/dev/null
Jan 30 05:43:12 Unraid kernel: ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x800000 action 0x0 frozen
Jan 30 05:43:12 Unraid kernel: ata4.01: SError: { LinkSeq }
Jan 30 05:43:12 Unraid kernel: ata4.01: failed command: CHECK POWER MODE
Jan 30 05:43:12 Unraid kernel: ata4.01: cmd e5/00:00:00:00:00/00:00:00:00:00/10 tag 0
Jan 30 05:43:12 Unraid kernel:          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Jan 30 05:43:12 Unraid kernel: ata4.01: status: { DRDY }
Jan 30 05:43:12 Unraid kernel: ata4.00: hard resetting link
Jan 30 05:43:12 Unraid kernel: ata4.01: hard resetting link
Jan 30 05:43:13 Unraid kernel: ata4.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Jan 30 05:43:13 Unraid kernel: ata4.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Jan 30 05:43:13 Unraid kernel: ata4.00: configured for UDMA/133
Jan 30 05:43:13 Unraid kernel: ata4.01: configured for UDMA/133
Jan 30 05:43:13 Unraid kernel: ata4: EH complete
Jan 30 06:20:09 Unraid kernel: ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x800000 action 0x0 frozen
Jan 30 06:20:09 Unraid kernel: ata4.01: SError: { LinkSeq }
Jan 30 06:20:09 Unraid kernel: ata4.01: failed command: CHECK POWER MODE
Jan 30 06:20:09 Unraid kernel: ata4.01: cmd e5/00:00:00:00:00/00:00:00:00:00/50 tag 0
Jan 30 06:20:09 Unraid kernel:          res 40/00:00:00:00:00/00:00:00:00:00/10 Emask 0x4 (timeout)
Jan 30 06:20:09 Unraid kernel: ata4.01: status: { DRDY }
Jan 30 06:20:09 Unraid kernel: ata4.00: hard resetting link
Jan 30 06:20:09 Unraid kernel: ata4.01: hard resetting link
Jan 30 06:20:10 Unraid kernel: ata4.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Jan 30 06:20:10 Unraid kernel: ata4.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Jan 30 06:20:10 Unraid kernel: ata4.00: configured for UDMA/133
Jan 30 06:20:10 Unraid kernel: ata4.01: configured for UDMA/133
Jan 30 06:20:10 Unraid kernel: ata4: EH complete

There is an unknown issue between the controller and the drive connected to the port associated with ata4.01. Probably no problem with the drive. Because these drives are in an emulated IDE mode, the drive attached to ata4.00 is also suffering the consequences, hard resets etc. A LinkSeq error is somewhat unusual, and here associated with a long timeout. I would shut down, and on reboot go into the BIOS settings and change the mode for your SATA ports to AHCI if available, otherwise a native SATA mode. That will change the modules used to handle these drives (and give the ata4.00 drive a little rest).

Since the error handler always recovers the drive, I don't believe there is any real harm done here, but still it is obviously an annoyance.

unRAID Server Release 4.7 "final" Available

Recommended Posts

Link to comment

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Posted Images

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Join the conversation