this is the info I pulled off to help to try and identify what is happening with my 0 byte share, thanks for any help in advance

Shares.pdf

You've set the share to only use a disk if it has more than 819 Gigabytes free  actually (800000000 * 1024 bytes free).  

You probably did not intend that as the value.  Min-Free is in kilobytes, not bytes.  

I have 18 - 2TB drives installed.

 

That's not quite what your web configuration page shows!  17 drives, most of which are 2TB!

 

a share was set up as Movies

 

I'm guessing that disk1 is excluded from your user shares, since it appears not to have a significant amount of files on it?

Your right it does not show as 18 - 2 tb drives, I have a number of spare drives which I have been popping in and out since this problem started showing up. I was trying to see if it was a matter  of the drives not being identified properly. The post after your solved the problem, thanks for the help.

 

 

Tom, is there any new news on a new beta?

If I preclear drives with the "-A" option, I should then expect to see 4-k Aligned on the device line in beta6a, correct?

yes

If I preclear drives with the "-A" option, I should then expect to see 4-k Aligned on the device line in beta6a, correct?

 

Correct.  (And the -A option should not be required if you have set the default as 4K aligned in unRAID.  preclear will default to the unRAID setting).

Well, so I did a test...

 

I have a key with 5.0beta2, 3x 1TB and 1x 500GB drives.  I precleared the drives with the -A option.  Assigned drives in 5.0b2.  copied over some data.  so far so good.

 

powerdown, put the flash drive in my pc, renamed bzimage to bzimage.52 and bzroot to bzroot.52. deleted the config/passwd shadow and smbpasswd.

 

Reconnect flash, power up, it sees all four drives as "MBR: Unaligned".  So I run "mkmbr /dev/sdd 64 0x83" on all four drives.  Refresh the web page, which now shows all drives as "MBR: 4K-aligned".  When I start the array after that step, the drives come up as unformatted, with the appropriate boxed to click and format, and click and start a parity check.

 

So I wanted to make sure that what I expected to be should have been and wasn't, which is Aligned drives all the way through.

 

Posted my syslog FWIW. 

 

I'm not concerned with this, it's just a test on what will eventually become my next tower, just making sure my expectations were right, and pass along more info on the outcome.

syslog.txt

5.0b2 DOES NOT understand 4K aligned drives.  If you precleared on 5.0b2 with -A unRAID would not give a rats behind and would format them with a starting sector at 63 and NOT 64.

 

So, no your expectations were not quite correct.

See, this is why I asked .  

 

But then why do the drives come up when I used the "mkmbr /dev/sd#", which defaults to 63 and 0x83 as unformatted?  Should the array have come up when that was run after the mkmbr 64?

 

Never mind.  When I ran "mkmbr /dev/sd#", the array started, but wanted to correct parity.  Everything else looked good.

 

Gonna pre-clear again with the -A, and see if it makes any difference in performance of the array.

I don't much like the terminology "unaligned".  Sounds like like your drives are not right with the universe.  Truth is unaligned is a fine state for any drive manufactured up to about 6 months ago.  Starting then, some drive manufacturers started using 4k sectors internally, although the drives still look externally like they are 512 byte sectors.  This configuration creates performance problems if the partition starting sector is not divisible by 4.  Unaligned partitions start at sector 63 (hence not aligned because 63 is not divisible by 4), while aligned start at sector 64 (which is aligned because 64 is divisible by 4).  THERE IS NO NEED AT ALL TO CHANGE FROM UNALIGNED TO ALIGNED FOR EXISTING DISKS.

When I say alignment, I'm thinking partition alignment.  Are we talking about the same thing?

 

If it is, then yes, when partitions are aligned, during testing in my environment (Apples to Oranges, SAN backed SQL Windows Servers vs. my puny unraid array), we saw about 35% increase in performance.

 

If it's not, then i'm missing the boat on what we're actually aligning when running preclear with the -A flag.

... powerdown, put the flash drive in my pc, renamed bzimage to bzimage.52 and bzroot to bzroot.52. deleted the config/passwd shadow and smbpasswd.

 

Reconnect flash, power up ...

 

So, what O/S is your machine supposed to be running at this stage? 

So, what O/S is your machine supposed to be running at this stage? 

 

The banner on the page says "unRAID Server Plus version: 5.0-beta6a"

 

At the CLI,

 

 

root@tower:~# uname -a

Linux tower 2.6.36.2-unRAID #8 SMP Tue Feb 22 16:29:25 MST 2011 i686 Intel® Atom CPU  330  @ 1.60GHz GenuineIntel GNU/Linux

 

When I say alignment, I'm thinking partition alignment.  Are we talking about the same thing?

 

If it is, then yes, when partitions are aligned, during testing in my environment (Apples to Oranges, SAN backed SQL Windows Servers vs. my puny unraid array), we saw about 35% increase in performance.

 

If it's not, then i'm missing the boat on what we're actually aligning when running preclear with the -A flag.

 

Yes, we are talking about the alignment of the partition on the disk.  unaligned=starting on sector 63, aligned=starting on sector 64.

So, what O/S is your machine supposed to be running at this stage? 

 

The banner on the page says "unRAID Server Plus version: 5.0-beta6a"

 

In this case, at some point after renaming bzimage and bzroot, you must have copied the 5.0b6 versions of these files onto to your flash drive.  From your description, you had (re)moved the existing bzimage/bzroot, but not replaced them!

Yea, forgot to mention that step although I did do it, I did copy those files from the downloaded zip file, following the readme instructions.  But ran into a new self inflicted problem...

 

FWIW, DO NOT run the mkmbr against the flash drive.  Did it by mistake last night and rebooted this morning.  Got a "No operating system found, please insert ...." message.  Only downside is that I was at work and rebooted remotely after the preclear .  So went the whole day wondering what was wrong with my test rig...  It's the only thing I can think of.

 

The folly of not paying attention

Ooops - yes, I think that you will have to rebuild your flash drive.

Ooops - yes, I think that you will have to rebuild your flash drive.

You might just need to run syslinux on it.  The contents on the partition are probably fine.

 

Joe L.

No worries, I tried running the opposite mkmbr, and syslinux again to no avail.  I had however created an image of the usb key before I started all this.  Found a neat little program called usbit that creates an image file.  Only "odd" thing is that after I restored the key, it took somewhat longer than "normal" to boot the key. 

 

Thanks for the help all in my excitement

unRAID 5.0b6a has changed the default parity check mode to "NOCORRECT", meaning that any sync errors found are not addressed by updating parity to bring it in sync with the data.  This is a good thing for routine checks, beause parity should not fall out of sync, and if it does it is quite possible that an errant disk is at fault and not the parity disk.  In such a case, you don't want parity to be updated without giving you a chance to investigate.

 

This NOCORRECT default appears to also apply to parity checks that occur after a dirty shutdown.  This type of parity check frequently results in a few parity errors, particularly early in the disk, but sometimes in other areas as well.  These errors are becuase the parity disk does not contain a journaled filesystem and therefore is not as good at preserving data from a power failure as are the RFS formatted data drives.  To avoid having to run another correcting parity check, if this happens to you, you might want to stop the system initiated check, then give the RFS drives a couple minutes to complete their replay of transactions (optional), click the checkbox to run a correcting check, and then start the parity check.  Any parity checks found will then be corrected as they go.

 

Perhaps Tom can confirm this behavior.  I am not 100% sure if the check is correcting or not, as my (unexpected) test did not net any parity errors.  But the syslog indicates a noncorrecting check.  unRAID does not tell you whether the check is correcting or not while it is running - this would be a useful enhancement IMO.

I have found a permissions issue.  If you move files from one disk to another using the "mv" command from a telnet prompt, the permissions on the files in the new location make the files inaccessible via samba shares. 

 

New directories and files get the permissions 700 and are owned by root.

 

It is fixable with the newperms script.

Its been a month since Beta6a was released and there has been no resolution to these problems.

pras1011, you've poked at limetech multiple times throughout this thread. He'll respond/update when he's ready. The project hasn't been abandoned or anything like that please have some patience. 4.7 is working fine, 5.0 is a beta, there's no time line on it whatsoever.