Page 1 of 2 12 LastLast
Results 1 to 25 of 33
  1. #1

    Angry did I just kill my server witht this command ?!?

    Ok I'm running centos 5 x64 and doing some testing on new servers that just had all software installed.

    I was reading a topic somewhere and someone mentioned this command that they used to test the speed of their hdd raid:

    dd if=/dev/zero of=/dev/sda bs=1M count=1000

    So I thought that cant do no harm if someone else is running it so I ran it (except I did it with count=10000 because with 1000 it finished too quick as its a 15k SAS RAID10)

    Anyway, so a little while later I goto the dc and connect to this server to run some tests, one of them being "arcconf getconfig 1" to retrieve details about the raid...

    It doesnt react ... so I run it again .. nothing. Then suddenly it says can't open some log file in /var/log and still doesn't run (I was able to open the same file myself using pico without problems)

    So I goto cli and "shutdown -r now" and BOOOM tons of errors all over the screen incl. ext3 related stuff. After a few mninutes of pages and pages of errors, I power off/on the box and it comes back. I enter the adaptec bios and it shows the array as "Optimal" but then when I goto boot ... nothing, doesnt recognize the boot media.

    So I run linux rescue from the centos cd and it tells me that that partition table is UNREADABLE and that the only thing it can do is re-initialize the drives causing loss of all data.

    Apologies for the long description I just wanted to be detailed.

    Anyway, so here I am ..reinstalling centos on this box. Now I want to know if the command that I ran above would/could have caused damage to the partition table or if its more likely to be a hardware (raid controller) problem ????

    Scary thing is I ran the SAME command on 5 other IDENTICAL servers and they all seem ok (so far) but I havent tried rebooting them yet

  2. #2
    yep looks like I've killed them sll ... just rebooted snother one snd ssme issue, partition table ****ed.

    Wow, what A DOUCHE. I feel like such a spastic now.

    You'd think after 10 years in the biz I'd know better than to simply run a command like that without first making 100% sure it can do damage.

    Oh well 2 days of work lost. But I'm happy believe it or not. It's just software and I can reinstall that easily since these boxes are not live yet... I was worried it was the RAID controller that ****ed up (due to some previous issues with it in relation to its BIOS). Happy to know the raid controller didnt do anything wrong

  3. #3
    Join Date
    Aug 2002
    Location
    Milton Keynes
    Posts
    354
    Oh this is too funny.

    I guess we live and learn Care to name & shame where this 'advice' came from?

  4. #4
    Ouch.... Sounds like one of those days. Good thing it's nothing serious other than the software

  5. #5
    wasn't advice really ..just someone mentioning they used that to test the speed of their HDDs (think it was one of those "vibrating fans killed my hdd" threads

    but yeah ... its friggin insane and funny at the same time. But I am REEEALLL happy it wasnt the controller that did something as my initial assumption was and I was already starting to consider which controller to replace it with and how much of a huge hassle that is going to be

    as it stands its just a bunch of os/cpanel reinstalls ... pain in the arse but I AM in the process of stress testing these boxes before they go live at the end of the month, so this is kinda giving them a bit of a workout.

  6. #6
    Join Date
    Jan 2001
    Location
    Miami, FL
    Posts
    1,075
    really...

    hdparm for the win...

    i use dd responsible though....

    sorry to hear that you killed your box....

    i hope u were able to sleuth out the data.
    Biznesshosting, Inc. DBA VOLICO - Intelligent Hosting Solutions
    East Coast Enterprise Dedicated Servers and Miami Colocation.
    managed and unmanaged dedicated servers. High bandwidth colocation. Managed clusters.

  7. #7
    Join Date
    Oct 2009
    Posts
    865
    Heh, well.. you could indeed use that command to test the sequential write speed of a RAID. But it would be a destructive test, essentially zero-filling the first 10GB of the disk.

  8. #8
    Join Date
    Mar 2003
    Location
    Canada
    Posts
    9,072
    Ugh. Sounds like someone trolled you... next time, if you're not 100% sure what the command does, don't run it as root. :]

  9. #9
    Join Date
    Aug 2001
    Location
    Canada
    Posts
    2,124
    Quote Originally Posted by papi View Post
    dd if=/dev/zero of=/dev/sda bs=1M count=10000

    Scary thing is I ran the SAME command on 5 other IDENTICAL servers and they all seem ok (so far) but I havent tried rebooting them yet

    I really hope those are not production servers; you overwrite the first 10GB of raw data... those 5 servers should be toast as well. sorry

    if = input
    of = output
    bs = blocksize
    count = count

  10. #10
    Join Date
    Mar 2009
    Location
    deep blue yonder
    Posts
    176
    On the off change you're still keen on running the test, replace the original of= with of=foofile and you should be good to go. Remember to remove the foofile when you're done.
    424 bits were harmed in the making of this signature.

  11. #11
    Join Date
    Aug 2003
    Posts
    2,004
    That is pretty amusing. Lesson learned. When I was a newbie I once did yum uninstall libstdc++. That caused one helluva night.

  12. #12
    Join Date
    Feb 2010
    Location
    Ohio, USA
    Posts
    120
    Nice.

    Hope proper backups were kept ; )
    error mounting /proc: No such file or directory
    error mounting /sys: No such file or directory
    Kernel panic - not syncing: Attempted to kill init!

    ..OMG they tried to kill init.. you b@stards.

  13. #13
    no backups, these were not live boxes!

    I'm surprised no one asked yet what ths epeed result was anyway ... 770 megajigabytespersec!! Haha

  14. #14
    Join Date
    Feb 2010
    Location
    Ohio, USA
    Posts
    120
    Quote Originally Posted by papi View Post
    I'm surprised no one asked yet what ths epeed result was anyway ... 770 megajigabytespersec!! Haha
    Nah the zeroing over of your disk is far more amusing than any speed result.
    error mounting /proc: No such file or directory
    error mounting /sys: No such file or directory
    Kernel panic - not syncing: Attempted to kill init!

    ..OMG they tried to kill init.. you b@stards.

  15. #15
    Join Date
    Jun 2004
    Location
    Oregon
    Posts
    1,315
    Quote Originally Posted by papi View Post
    no backups, these were not live boxes!

    I'm surprised no one asked yet what ths epeed result was anyway ... 770 megajigabytespersec!! Haha
    that test uses buffer, so it's not accurate at all.
    if you want to test the real disk speed, you should use dd with oflag=dsync.

    so you basically killed your OS by running a not accurate speed test

  16. #16
    Damnit man!

    So um would this be perfectly safe to run ?

    dd if=/dev/zero of=tempfile bs=1M count=10000 oflag=dsync

  17. #17
    Join Date
    Mar 2009
    Location
    Austin, TX
    Posts
    935
    Quote Originally Posted by papi View Post
    Damnit man!

    So um would this be perfectly safe to run ?

    dd if=/dev/zero of=tempfile bs=1M count=10000 oflag=dsync
    Yes, above is safe. Just make sure your PWD is where you want to be and have more than 10GB free.

  18. #18
    Join Date
    Mar 2009
    Location
    deep blue yonder
    Posts
    176
    Quote Originally Posted by papi View Post
    Damnit man!

    So um would this be perfectly safe to run ?

    dd if=/dev/zero of=tempfile bs=1M count=10000 oflag=dsync
    Yup.
    Code:
    $ dd if=/dev/zero of=tempfile bs=1M count=10000 oflag=dsync
    10000+0 records in
    10000+0 records out
    10485760000 bytes (10 GB) copied, 120.788 seconds, 86.8 MB/s
    
    $ ls -l
    -rw-rw-r--  1 test test 10485760000 Nov 16 18:21 tempfile
    
    $ rm tempfile
    Last edited by TDS-chriss; 11-16-2010 at 02:27 PM. Reason: added file listing and removal
    424 bits were harmed in the making of this signature.

  19. #19
    Join Date
    Mar 2008
    Location
    Los Angeles, CA
    Posts
    555
    I usually use direct I/O as it gives the lowest CPU usage and bypasses the OS/s buffers. I have seen DD get bottlenecked by CPU usage if not using direct before:

    Writes:
    root@dekabutsu: 10:16 PM :/data# dd bs=1M count=5000 oflag=direct if=/dev/zero of=./5gb.bin
    5000+0 records in
    5000+0 records out
    5242880000 bytes (5.2 GB) copied, 7.20372 s, 728 MB/s

    Reads:
    root@dekabutsu: 10:16 PM :/data# dd bs=1M iflag=direct if=./5gb.bin of=/dev/null
    5000+0 records in
    5000+0 records out
    5242880000 bytes (5.2 GB) copied, 6.41051 s, 818 MB/s

  20. #20
    Join Date
    Mar 2009
    Location
    Austin Tx
    Posts
    2,007
    Yup, dd can kill. I only use it in dev environments to test I/O, etc. I've never had the guts to run it on a good HDD on a production server. I have on a PFed HDD, but hey, it was dying anyway...
    You live, you learn. That's why God invented backups.
    This is the best signature in the world....Tribute!
    (It is not the best signature in the world, no. This is just a tribute)

  21. #21
    Quote Originally Posted by houkouonchi View Post
    I usually use direct I/O as it gives the lowest CPU usage and bypasses the OS/s buffers. I have seen DD get bottlenecked by CPU usage if not using direct before:

    Writes:
    root@dekabutsu: 10:16 PM :/data# dd bs=1M count=5000 oflag=direct if=/dev/zero of=./5gb.bin
    5000+0 records in
    5000+0 records out
    5242880000 bytes (5.2 GB) copied, 7.20372 s, 728 MB/s

    Reads:
    root@dekabutsu: 10:16 PM :/data# dd bs=1M iflag=direct if=./5gb.bin of=/dev/null
    5000+0 records in
    5000+0 records out
    5242880000 bytes (5.2 GB) copied, 6.41051 s, 818 MB/s
    Hmm with same commands I'm getting 280 MB/s write and 300MB/s read. This is 4 x 15k7 Cheetah SAS in RAID10 (Adaptec 5405 / default stripe size of 256Kb)

    How are you getting so much faster speeds .. what's your setup?

  22. #22
    Join Date
    Mar 2008
    Location
    Los Angeles, CA
    Posts
    555
    Quote Originally Posted by papi View Post
    Hmm with same commands I'm getting 280 MB/s write and 300MB/s read. This is 4 x 15k7 Cheetah SAS in RAID10 (Adaptec 5405 / default stripe size of 256Kb)

    How are you getting so much faster speeds .. what's your setup?
    I would expect the read speeds to be a bit better than that as with raid10 ur read speeds should be about double the write speeds unless the controller is not reading from all disks (I know some that don't but I thought adaptec did). This is on 20x2 TB hitachi disks (7200 RPM) in raid6 on an ARC-1280ML controller. Its a pretty dated controller. The new ARC-1880 gets about 1.4 gigabyes/sec read and 900 megabytes/sec write with the same amount of drives in raid6.

  23. #23
    ah ok 5 times as many spindles ..sweet, makes sense now

    Anyway, just out of curiosity I upped the size of the blocks to 10M and got these crazy speeds .. hmm ?

    /home]# dd bs=10M if=/dev/zero of=tmpfile count=100 iflag=dsync
    100+0 records in
    100+0 records out
    1048576000 bytes (1.0 GB) copied, 1.00776 seconds, 1.0 GB/s

    Woo fast but ok probably not big enough..so here we go again

    [/home]# dd bs=10M if=/dev/zero of=tmpfile2 count=1000 iflag=dsync
    1000+0 records in
    1000+0 records out
    10485760000 bytes (10 GB) copied, 20.9969 seconds, 499 MB/s

    [/home]# dd bs=10M if=tmpfile2 of=/dev/null count=1000 iflag=dsync
    1000+0 records in
    1000+0 records out
    10485760000 bytes (10 GB) copied, 2.6184 seconds, 4.0 GB/s

    that looks kinda crazy fast but I'm sure it's just something to do with the much larger block size (duhh). Mind doing that on yours?

  24. #24
    Join Date
    Mar 2008
    Location
    Los Angeles, CA
    Posts
    555
    How much ram does ur system have? This is likely the OS cache. I doubt you will ever get results like that if you use iflag/oflag direct instead of dsync. If you do very small data (<512 MB) then u will get really high speeds as it will just be hitting the raid controllers cache.

  25. #25
    Join Date
    Apr 2009
    Location
    Nevada
    Posts
    662
    The i/o rates does not look pretty for us. Maybe because its running a RAID6.

    PHP Code:
    [root@ezeelogin.com ~]# dd if=/dev/zero of=/home/test count=20000 bs=512K oflag=dsync
    20000+0 records in
    20000
    +0 records out
    10485760000 bytes 
    (10 GBcopied72.1454 seconds145 MB/s
    [root@ezeelogin.com ~]# dd if=/dev/zero of=/home/test count=20000 bs=512K oflag=dsync
    [root@ezeelogin.com ~]# dd if=/dev/zero of=/home/test count=20000 bs=1M oflag=dsync
    20000+0 records in
    20000
    +0 records out
    20971520000 bytes 
    (21 GBcopied145.504 seconds144 MB/s
    [root@ezeelogin.com ~]# dd if=/dev/zero of=/home/test count=1024 bs=1M oflag=dsync,direct
    1024+0 records in
    1024
    +0 records out
    1073741824 bytes 
    (1.1 GBcopied9.48617 seconds113 MB/
    James B
    WWW.EZEELOGIN.COM |Setup your Secure Linux SSH GatewayMEET PCI DSS & ISO 27001 Compliance|Manage & Administer Multiple Linux Servers Quickly & Securely.

Page 1 of 2 12 LastLast

Similar Threads

  1. Kill command options
    By adsbarish in forum Hosting Security and Technology
    Replies: 6
    Last Post: 11-11-2008, 05:31 PM
  2. Want Witht and without www point same dom DirectAdmin
    By danyboy2010 in forum Web Hosting
    Replies: 10
    Last Post: 04-20-2008, 11:20 AM
  3. Mysql Kill user command?
    By mifa in forum Hosting Security and Technology
    Replies: 2
    Last Post: 03-19-2008, 06:34 AM
  4. What can be the problem witht his traceroute?
    By AmericanD in forum Hosting Security and Technology
    Replies: 3
    Last Post: 11-02-2002, 11:21 AM
  5. Free Web Hosting witht he works
    By CritticAge in forum Shared Hosting Offers
    Replies: 9
    Last Post: 06-08-2002, 09:33 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •