Hey everyone ....

 

For a long time now, I have been putting plans to paper for a media server. With the installation of my structured wiring in sight, I am now close to pulling the trigger on those plans and I find myself leaning towards Unraid with one issue causing me to think twice. I have read reports of existing Media streamed off an Unraid box stuttering when another user opens a folder on a spun-down disk.

 

From what I have read, this is a common issue for Unraid users and it's one for me that is inconsistent with Unraid's occupation of the sweet spot for media streaming with redundancy.

 

Is there an end in sight to this issue. I really want Unraid to be the one.

 

Kind regards,

 

Ash

Hey everyone ....

 

For a long time now, I have been putting plans to paper for a media server. With the installation of my structured wiring in sight, I am now close to pulling the trigger on those plans and I find myself leaning towards Unraid with one issue causing me to think twice. I have read reports of existing Media streamed off an Unraid box stuttering when another user opens a folder on a spun-down disk.

 

From what I have read, this is a common issue for Unraid users and it's one for me that is inconsistent with Unraid's occupation of the sweet spot for media streaming with redundancy.

 

Is there an end in sight to this issue. I really want Unraid to be the one.

 

Kind regards,

 

Ash

I'm guessing here, but I think this is more a Linux issue than unRAID.    I think the underlying cause is the use in the Linux kernel of what is known as the "Big Kernel Lock" by the low level device driver AND also by the networking drivers.    Depending on the network interface, it might exist, or not. 

 

As of today, the reiserfs file-system used by unRAID does use the "BKL" lock.  It is probably in effect while waiting for a sleeping drive to spin up... and if your network does not have enough content buffered, and your network interface also uses that same lock, it will wait for the disk to spin up.

 

There is hope, as there is a huge effort to get rid of the "Big Kernel Lock" in the reiser file-system (and in all of Linux) as it was a kludge added when SMP was first introduced.

This thread of messages shows the work has been done as of a week or so ago, and is in the testing phase.  I think it will make a huge difference. http://marc.info/?t=124906247100005&r=1&w=2

In coming months expect it will soon be in the Linux kernel for everyone and from what I've read, it will improve the performance for all.  Tom usually keeps unRAID up to the latest stable Kernel, so soon after the fixes are in the Kernel, we'll likely have them too.

 

In the interim, you can set the drive to only spin down when not accessed in up to 9 hours...  and you can set the spin-down to "never" if you desire.

There is also the choice of setting spin down time high and spinning up all your drives before any activity where there could be simultaneous access.

Thank you for the replies. It seems there is a short-term workable solution and a permanent solution in the wings. Aside from the extra power required, what are the impacts of keeping drives spun up much longer? I was wondering what the impact is on the longevity of drives by spinning them up and down versus just letting them run 24/7.

 

Regards,

 

Ash

There are many factors in the 24/7 spinning.

 

1. Manufacture.

2. Spindle Speed

3. Environmental.

 

I've had maxtor 5400 RPM drives which would fail in the 1.5 to 2.5 year range.

I've had WD 7200 drives which spun for 3 years without issue. I usually removed them from service before they failed.

My 10,000 RPM Scsi drives fail within the 2-4 year range. Depending on environmental conditions. Heat is always an issue with these drives.

 

I've often had concern about drives spinning up and down all day long.

I've not seen a failure with the drives in my unRAID server, however they are recent 1TB WD Green and Seagate 7200.12 drives.

 

 

There are many factors in the 24/7 spinning.

 

1. Manufacture.

2. Spindle Speed

3. Environmental.

 

I've had maxtor 5400 RPM drives which would fail in the 1.5 to 2.5 year range.

I've had WD 7200 drives which spun for 3 years without issue. I usually removed them from service before they failed.

My 10,000 RPM Scsi drives fail within the 2-4 year range. Depending on environmental conditions. Heat is always an issue with these drives.

 

I've often had concern about drives spinning up and down all day long.

I've not seen a failure with the drives in my unRAID server, however they are recent 1TB WD Green and Seagate 7200.12 drives.

 

 

Most current disk drives have "Fluid Bearings" ( http://en.allexperts.com/e/f/fl/fluid_bearing.htm )

They have way less friction than the older ball-bearings in previous generations of disks, and are expected to have much longer lifetimes.

I would worry more about loading and un-loading of the disk heads when spinning up and down than with leaving them spinning.

 

As already said, a dust-free, temperature controlled environment also helps.  A UPS to eliminate un-expected head retraction helps. 

 

All drives eventually fail...  it is why we have RAID based servers.

 

Joe L.

As of today, the reiserfs file-system used by unRAID does use the "BKL" lock.  It is probably in effect while waiting for a sleeping drive to spin up... and if your network does not have enough content buffered, and your network interface also uses that same lock, it will wait for the disk to spin up.

 

There is hope, as there is a huge effort to get rid of the "Big Kernel Lock" in the reiser file-system (and in all of Linux) as it was a kludge added when SMP was first introduced.

That's interesting.  I've curently got all my files spread across 3 drives in my linux box (ubuntu), and all 3 of my media players draw files from it.  We access files all the time while we are watching content on other players and have never experienced anything like this even when pulling HD material (higher bitrate).  I have no doubt this is real, just never experienced it once in 2 years.  We'll see when i get my unraid box together this week if it has this issue for our setup.

As of today, the reiserfs file-system used by unRAID does use the "BKL" lock.  It is probably in effect while waiting for a sleeping drive to spin up... and if your network does not have enough content buffered, and your network interface also uses that same lock, it will wait for the disk to spin up.

 

There is hope, as there is a huge effort to get rid of the "Big Kernel Lock" in the reiser file-system (and in all of Linux) as it was a kludge added when SMP was first introduced.

That's interesting.  I've curently got all my files spread across 3 drives in my linux box (ubuntu), and all 3 of my media players draw files from it.  We access files all the time while we are watching content on other players and have never experienced anything like this even when pulling HD material (higher bitrate).  I have no doubt this is real, just never experienced it once in 2 years.  We'll see when i get my unraid box together this week if it has this issue for our setup.

Ah, but are you using reiserfs file-systems on your ubuntu box?  They are the ones using the big-kernel-lock.  Tom has said that he choose the reiserfs because of the lack of a need to specify the number of inodes when the file system is created, and the ease of which it could be "expanded" to use the size of a larger disk when disks are replaced.  He has also said he wants to be able to use other file-system types in the future... so at that time I guess we'll learn more. So far, all that is supported is reserfs.

 

Also... what disk scheduling algorithm is used on ubuntu?  I think ubuntu uses "cfq", while unRAID has as default "noop"  It might be another thing to play with.

 

Joe L.

i couldn't tell you what scheduler was beign used in ubuntu.  all the drives are formatted ext3, though I'd probably go with ext4 now with it's added performance.  that's probably the difference I'm seeing versus what people are saying about unRaid with the reiserfs.  Hopefully, this won't be an issue too long for unraid as we stream lots of content.

 

thanks for spreading the knowledge.

c+h

i couldn't tell you what scheduler was beign used in ubuntu.  all the drives are formatted ext3, though I'd probably go with ext4 now with it's added performance.  that's probably the difference I'm seeing versus what people are saying about unRaid with the reiserfs.  Hopefully, this won't be an issue too long for unraid as we stream lots of content.

 

thanks for spreading the knowledge.

c+h

 

The reiserfs is plenty fast enough for reads.

The performance issue I've come against with reiserfs is in deletes of very large file or creation of a new file with a disk that is near capacity.

In my experience, ripping a DVD to a disk that already has a large amount of files creates an enourmous delay if the superblock or inodes are not already in memory.

 

In fact sometimes it's such a delay that the Windows/Samba connection times out.

Once the file is created in the directory and open, writes go to the file system as fast as unRAID with parity protection can.