Samba question

[muungwana]

Would using the

fdatasync  or fsync
             

option with dd give more accurate results?

dd  if=/dev/zero of=/home/user/dd-test  bs=200M count=1 conv=fsync
My results on a 4 core CPU ......  as I have always found in the past using urandom is very heavy (time wise) and delays dd greatly.
I had tried using it for wiping HDDs but had to give it up due to the slow down in the process.

fsync would just slow you down further

I found the best way to wipe hard drives is to open cryptsetup PLAIN mapper with a random key against a drive and then write random data to the disk by blasting zeros to the encrypted mapper. Here is an example of how to do it,you have to run this from root terminal

[root@mtz ink]# cryptsetup create test test.img
Enter passphrase:
[root@mtz ink]# dd if=/dev/zero of=/dev/mapper/test bs=200M count=1
[root@mtz ink]# cryptsetup remove test

The third argument of the cryptsetup command is a path to a file or drive you want to write random data to.
The second argument is a name that will show up in "/dev/mapper"

zuluCrypt has an ability to write random data to a device much faster compared to "dd" command by using the above technique.

[Just17]

fsync would just slow you down further

How ...  writing the meta data?

could use fdatasync if you wanted to omit that.

From what I can see all it does is wait until the file is completely written before checking the time.

How does using this compare to the script results?

[muungwana]

How ...  writing the meta data?

most file systems increase performance by caching data in memory and then commit them to disk after a period of time or after there is too much data on the cache.If i remember correctly,with ext3 file system.When you write data to a disk,your data is guaranteed to be on the disk after atleast 5 seconds later on,original implementation of ext4 was more than 100 seconds later.

when you use fsync,you commit to disk on every write and that will slow you down considerably because hard drives are very slow.
could use fdatasync if you wanted to omit that.

From what I can see all it does is wait until the file is completely written before checking the time.

Yap.Thats the point.
It reads data from memory and commit it to disk.
It then tell you how long the operation took and calculate for you the transfer rate
You can do it manually,but then you will have to do the calculations yourself.

Its more accurate reflection of the rate at which the file system writes data to disk since it doesnt task the CPU and hence the time it takes is not bound by CPU performance compared to using dd command with "/dev/urandom" as source.If you use "/dev/random".The time the operation will take will be much,much longer.The point being,its not appropriate to use "dd" command with these random number generators when testing how fast the file system can write data to disk because the bottleneck will not be on the hard drive but on the CPU generating random data.

How does using this compare to the script results?

what script?

[Just17]

How ...  writing the meta data?

most file systems increase performance by caching data in memory and then commit them to disk after a period of time or after there is too much data on the cache.If i remember correctly,with ext3 file system.When you write data to a disk,your data is guaranteed to be on the disk after atleast 5 seconds later on,original implementation of ext4 was more than 100 seconds later.

when you use fsync,you commit to disk on every write and that will slow you down considerably because hard drives are very slow.
could use fdatasync if you wanted to omit that.

From what I can see all it does is wait until the file is completely written before checking the time.

Yap.Thats the point.
It reads data from memory and commit it to disk.
It then tell you how long the operation took and calculate for you the transfer rate
You can do it manually,but then you will have to do the calculations yourself.

Its more accurate reflection of the rate at which the file system writes data to disk since it doesnt task the CPU and hence the time it takes is not bound by CPU performance compared to using dd command with "/dev/urandom" as source.If you use "/dev/random".The time the operation will take will be much,much longer.The point being,its not appropriate to use "dd" command with these random number generators when testing how fast the file system can write data to disk because the bottleneck will not be on the hard drive but on the CPU generating random data.

How does using this compare to the script results?

what script?

Sorry ./SpeedTest from previous page.

Other than that I see nothing in your post which disagrees with anything I posted.


...  I suggested fsdatesync, disagreed with the use of urandom because it slows everything down .......

What I would like to see is comparison figures between using      dd if=/dev/zero with conv=fsync or fsdatasync  and using any other method of testing the write speed.

How do the figures compare?

[dudeonthebayou]

I seem to get bad result no matter if i use /dev/urandom or /dev/zero . I will try bypassing the controller card and go straight on the sata port.


The result i get by removing the controller card and hook the harddrive directly into the sata port on the motherboard is.

/dev/urandom      36.0786s  5.8 MB/s
/dev/zero           1.587s      134 MB/s


hdparm -tT /dev/sda

/dev/sda:

Timing cached reads: 1960 MB in 2.00 seconds = 980.34 MB/sec
Timing buffered disk reads: 360 MB in 3.01 seconds = 119.49 MB/sec

[muungwana]

Other than that I see nothing in your post which disagrees with anything I posted.


...  I suggested fsdatesync, disagreed with the use of urandom because it slows everything down .......

What I would like to see is comparison figures between using      dd if=/dev/zero with conv=fsync or fsdatasync  and using any other method of testing the write speed.

How do the figures compare?

http://www.informit.com/articles/article.aspx?p=23618&seqNum=5

The link above seem to suggest the two options above do the same thing in recent linux kernels.

I guess my objection is on the use of dd command.The random number generators slows down the process too much and "/dev/zero" source speeds it up too much since the system seem recognize its writing zeros and optimize them.

Just got an idea,i use another file as source input and it worked.Another file seem to be a better source but then you will be doing read operation on the source file and a write operation on the destination file and you will no be testing write operation only.

[pags]

I seem to get bad result no matter if i use /dev/urandom or /dev/zero . I will try bypassing the controller card and go straight on the sata port.


The result i get by removing the controller card and hook the harddrive directly into the sata port on the motherboard is.

/dev/urandom      36.0786s  5.8 MB/s
/dev/zero           1.587s      134 MB/s


hdparm -tT /dev/sda

/dev/sda:

Timing cached reads: 1960 MB in 2.00 seconds = 980.34 MB/sec
Timing buffered disk reads: 360 MB in 3.01 seconds = 119.49 MB/sec

Ah!  Back to the OP!

Results look better, so maybe some hardware issue, there...

How much memory does this PC have?  Perhaps there are additional caching issues.  While copying across the network will (almost) always be slower than local, you do need good local performance before blaming the software 

Another FYI (comparing networks):
Local (on another PC)

Code: [Select]

dd if=/dev/zero of=test.img bs=200M count=1
1+0 records in
1+0 records out
209715200 bytes (210 MB) copied, 4.63657 s, 45.2 MB/s

Across the network (mounted Samba share):

Code: [Select]

dd if=/dev/zero of=mnt/smb/test.2.img bs=200M count=1
1+0 records in
1+0 records out
209715200 bytes (210 MB) copied, 18.2955 s, 11.5 MB/s

This is a 100Mbit network that handles video to XBMC fine...
...

Does the new hardware improve your network performance?

[dudeonthebayou]

This is copied to a network drive over a Gigabit network.

[root@localhost ~]# dd if=/dev/zero of=/mnt/Matt/test11.img bs=200M count=1
1+0 records in
1+0 records out
209715200 bytes (210 MB) copied, 2.35632 s, 89.0 MB/s

[root@localhost ~]# dd if=/dev/urandom of=/mnt/Matt/test12.img bs=200M count=1
1+0 records in
1+0 records out
209715200 bytes (210 MB) copied, 42.0424 s, 5.0 MB/s
[root@localhost ~]#

[muungwana]

@dudeonthebayou

our apologies if we seem to be rumbling among ourselves and not address your issue,we generally dont do this kind of thing.

Those results seem to suggest a local issue with how fast your hard drive can accept data.

Do you experience it somewhere else?,your computer should be running slower in some respects as a result of it.

[dudeonthebayou]

That is quite alright.  I did another test by copying data from a network drive to the linux system using the dd command.

[root@localhost ~]# dd if=/mnt/Matt/test12.img of=/root/test14.img
409600+0 records in
409600+0 records out
209715200 bytes (210 MB) copied, 3.74758 s, 56.0 MB/s

Now these are relatively small files to copy over a network. I do notice that when I copy something over the network the linux system does make a hiss or high pitch noise (it doesn't come from the harddrive), its like its reacting to the load. Like I said this is a old system that I was testing, it would be a shame to junk it if it could be used for just file storage.

[pags]

This is copied to a network drive over a Gigabit network.

[root@localhost ~]# dd if=/dev/zero of=/mnt/Matt/test11.img bs=200M count=1
1+0 records in
1+0 records out
209715200 bytes (210 MB) copied, 2.35632 s, 89.0 MB/s

[root@localhost ~]# dd if=/dev/urandom of=/mnt/Matt/test12.img bs=200M count=1
1+0 records in
1+0 records out
209715200 bytes (210 MB) copied, 42.0424 s, 5.0 MB/s
[root@localhost ~]#

Well, you appear to have good, raw network speed.
Again, caching...how much memory on the system acting as the server?  It may be able to fully cache the 200M file before committing to disk, thereby fully exploiting your network, but the 2G files may saturate the cache, and then the harddrive speed starts to impact the network, which has to wait...

That is quite alright.  I did another test by copying data from a network drive to the linux system using the dd command.

[root@localhost ~]# dd if=/mnt/Matt/test12.img of=/root/test14.img
409600+0 records in
409600+0 records out
209715200 bytes (210 MB) copied, 3.74758 s, 56.0 MB/s

Now these are relatively small files to copy over a network. I do notice that when I copy something over the network the linux system does make a hiss or high pitch noise (it doesn't come from the harddrive), its like its reacting to the load. Like I said this is a old system that I was testing, it would be a shame to junk it if it could be used for just file storage.

And there, you've nailed it.  If it works (for you) for file storage, it may be worth keeping (factor in increase electrical usage as compared to newer and/or dedicated hardware).  If the poor performance is a function of the hardware, it may have to get recycled...
 

[Just17]

Sorry to take this thread off topic again, but I received a communication from a friend who read the thread with some information which is pertinent to anyone interested in the off topic part.
I could think of no better place to post this, so apologies to dudeonthebayou for this further interruption.

Following is the information received:


The dd command with the flags fsync or fdatasync should give a correct result for measuring write speed of the disk.
Alternatively use the option  oflag=direct  to achieve reliable results.

The C programme and explanation is very close to being correct ... except this bit ...

The fifth command writes the file to disk

Not so; the write command will move the data to the kernel IO buffers and return. (... giving the appearance of a faster write speed than the drive max write speed ...)
Then the kernel will take on the job to effectively write the data to disk.

###
The man page of write(2) says the following:

NOTES
       A successful return from write() does not make any guarantee that data has been committed to disk.
In fact, on some buggy implementations, it does not even guarantee that space has successfully been reserved for the data.
The only way to be sure is to call fsync(2) after you are done writing all your data.
###

The C programme should use the O_SYNC flag on "open" to get the best results.

There is a small difference between the open flag O_SYNC, and calling fsync(fd) before closing the file, O_SYNC will force each "write" to return after the data has been committed, while fsync(fd) will flush the data only when explicitly called, typically before closing the file.

The C test program performs a single write, therefore there will be no difference between using one or the other in this program.


In normal circumstances a change in the content of the data will not affect the write speed - whether all zeroes or not. An exception would be where a compressed filesystem was in play.
The different results obtained are likely due to cache/buffers use.

[dudeonthebayou]

First of all the system has dual processors and 4GB DDR2 ECC memory.

I will do a few more tests, but thanks for the help. I don't remember it having any network speed issues while it was in production, but nothing lasts forever so I will continue trying to troubleshoot. It could be a faulty motherboard causing this.

I appreciate all the help.