FYI - Converting to XFS - much better write speeds

[opentoe]

From converting to XFS from ReiserFS I now get sustained transfer rates without using a cache drive of 80MB/sec. My sustained write speed doubled! And from time to time I get 105MB/sec burts.

 

[garycase]

That's exceptionally fast for writes to the protected array => in fact it's unlikely unless there's some additional buffering going on, since each write requires 4 disk accesses.

 

I notice you have all 7200rpm WD Blacks, which certainly helps.    Are these drives most empty?  (which would mean the writes are all on the faster outer cylinders)

 

And what is the size of the files you're writing?

 

It'd be interesting to see what speeds you get if you do a single write with a very large amount of data [e.g. 20GB or more].

 

And are you CERTAIN these aren't cached writes?  [i notice you DO have a cache drive.]

 

 

[trurl]

Are you sure these speeds aren't affected by memory buffering? Linux will use all free RAM to buffer I/O. You will have to write enough to overfill memory to see what disk writing speed really is.

[garycase]

Are you sure these speeds aren't affected by memory buffering? Linux will use all free RAM to buffer I/O. You will have to write enough to overfill memory to see what disk writing speed really is.

 

Agree ... that's why I asked what kind of speed he sees with a single large copy (min 20GB ... preferably even more).

 

[opentoe]

Are you sure these speeds aren't affected by memory buffering? Linux will use all free RAM to buffer I/O. You will have to write enough to overfill memory to see what disk writing speed really is.

 

Agree ... that's why I asked what kind of speed he sees with a single large copy (min 20GB ... preferably even more).

 

I'll copy a large file a little later and see what consistent speed I get. I did just confirm ALL my shares are set:

USE CACHE DISK: NO

 

I'll get back.

 

[SSD]

Are you sure these speeds aren't affected by memory buffering? Linux will use all free RAM to buffer I/O. You will have to write enough to overfill memory to see what disk writing speed really is.

 

Agree ... that's why I asked what kind of speed he sees with a single large copy (min 20GB ... preferably even more).

 

I'll copy a large file a little later and see what consistent speed I get. I did just confirm ALL my shares are set:

USE CACHE DISK: NO

 

I'll get back.

 

Hmmm ... not sure that is enough.

 

If you used to have the use cache set to Yes, that then change it to No, I am not sure that the cache disks is not used.

 

I once had a cache only share, and then accidentally created a directory on another disk with the same name, and next thing I knew the cache drive contents had been moved to my array against my wishes. I went back and saw that the share setting still said "cache only". It seems to matter much more what the directories are in the root of your disks than what the share settings say.

[trurl]

Are you sure these speeds aren't affected by memory buffering? Linux will use all free RAM to buffer I/O. You will have to write enough to overfill memory to see what disk writing speed really is.

 

Agree ... that's why I asked what kind of speed he sees with a single large copy (min 20GB ... preferably even more).

 

I'll copy a large file a little later and see what consistent speed I get. I did just confirm ALL my shares are set:

USE CACHE DISK: NO

 

I'll get back.

 

Hmmm ... not sure that is enough.

 

If you used to have the use cache set to Yes, that then change it to No, I am not sure that the cache disks is not used.

 

I once had a cache only share, and then accidentally created a directory on another disk with the same name, and next thing I knew the cache drive contents had been moved to my array against my wishes. I went back and saw that the share setting still said "cache only". It seems to matter much more what the directories are in the root of your disks than what the share settings say.

I'm pretty sure that some users have changed a share to cache-only but it still got moved to the array because the share already had files on the array.

 

So, in addition to the "Use cache disk:" setting, you should also make sure the folders on the disks also conform to the setting you want.

 

To see what shares are already on the array you can

ls -la /mnt/user0

and to see what shares have files on cache

ls -la /mnt/cache

. Any files that show up in these lists are not part of any share, only top level folders are shares.

[garycase]

Brian may have hit on what's happening => you may still have a root folder on the cache drive with the share name; and the system may in fact cache writes as a result, even though you've changed the setting.

 

In any event, it's simply not possible to get 100MB/s writes to the protected array, so SOMETHING is impacting this.  Could be the writes are cached (if you still get 80-100MB/s writes with a large file that's almost certain);  could be the writes are small and you have enough memory that they're buffered and "seem" to finish quickly; etc.

 

Try writing directly to a disk share ... i.e. to \\Tower\disk2\<somefolder>\<filetocopy>

 

[opentoe]

Here is the read and write results of one large file. NOT using a cache. I jumped the gun (second time a reference made about a gun in one of my posts, someone really wants me dead) and saw 100MB/sec burst speeds for about 20-30 seconds during the beginning of a large file write and then it dropped down to 60MB/sec consistent. I think with RieserFS I was only able to get 40MB/sec writes with large files. I have yet to try a bunch of small files.

 

[tdallen]

I get speeds approaching and sometimes slightly exceeding 50MB/sec sustained copying bluray rips (44-48 typical).  I see blips in the 60MB/s range.  My situation is optimal, though - unRAID has decided my largely empty 6TB WD Red drive is the preferred data drive and I have a matching 6TB parity.  I've had some other problems with the 6TB drives, but no complaints about performance .