+ Reply to Thread
Page 17 of 23 FirstFirst ... 7 15 16 17 18 19 ... LastLast
Results 241 to 255 of 342

Thread: Linux - Tips, tweaks and alignment

  1. #241
    OCZ Tweaker b2bde4's Avatar Flag of Sweden
    Join Date
    Mar 2009
    Posts
    271
    Mobo: (ASUS) AMD 780G + SB700
    CPU: AMD 4850e
    RAM: 4GB
    Vid: Passive ATI 2600XT
    PSU: 620W
    HDD: Vertex 30GB, FW 1.5
    OS: Ubuntu (10.04)

    Default

    Thank you for taking your time posting your thoughts I'll try to address some of them.

    Quote Originally Posted by Paul_one View Post
    But, there's something that only cropped up a little, and wasn't fully answered (although t'was slightly).
    mkfs.ext3 (or 4) -E stripe-width=128 /dev/sda[1-15]

    Now, the MAN pages say this is just for RAID, and I can't help but look at the entry JUST above it (stride).. To me, stride looks like the more obvious choice - is that not so?
    A respectable Linux kernel programmer mentions stripe-width in his blog.

    Quote below extracted from: http://thunk.org/tytso/blog/2009/02/...se-block-size/
    Quote Originally Posted by Theodore Ts'o
    Once you do this, we’re almost done. The last thing to do is to create the file system. As it turns out, if you are using ext4, there is a way to tell the file system that it should try to align files so they match up with the RAID stripe width. (These techniques can be used for RAID disks as well). If your SSD has an 128k erase block size, and you are creating the file system with the default 4k block size, you just have to specify a strip width when you create the file system, like so:

    # mke2fs -t ext4 -E stripe-width=32,resize=500G /dev/ssd/root
    Quote Originally Posted by Paul_one View Post
    How can we be sure that this 4k "default" is actually there - and it isn't say 2k?
    According to the man page, the value used is the same as the value uses for the file system block size. I believe file system block size defaults to 4k.

    Quote Originally Posted by Paul_one View Post
    Now, I'd like to comment on some of the posts I remember.
    First off, the NOOP scheduler.
    Personally, I found performance degrade when using it on a previous (core v2) SSD.
    This is because it's a FIFO, meaning if I try to multi-task, the processes will fight and if I try to kick off something new while doing something in the background, it won't have a good chance as the queue is filled with requests already (at least that was my reasoning).
    CFQ has always given me the best "response" as the user, and I'd urge everyone to alter the grub setting (or enter 4 different grub settings) and switch between them over a couple of weeks to get "real" experience with them.
    To freely switch between different schedulers, you probably need more input/output per seconds than the core v2 is able to handle. Also, the experience probably depends on disk usage. As you pointed out, there's only one way to find out and that's trail and error.

    When I tried the different options I never noticed any significant difference between them with a light usage pattern.

    Quote Originally Posted by Paul_one View Post
    One final note:
    The tests are all invalid concerning the speed of reads/writes.
    ... They have all been performed on "securely erased" drives... Meaning that the SSD barefoot controller has a blank slate to work with.
    ...What you need to do is fill up the disk with zero's...
    Your suggestion won't work because it would only represent the worst case scenario. During normal operation the disk would slowly fill up over time. The time it takes for the disk to fill up depends on the usage pattern. During normal operation, not every write operation writes to a completely new block. Most writes probably translates to a re-write of an 'old' block.

    I believe there was at least one test done after installation.

    Quote Originally Posted by Paul_one View Post
    All exciting .
    That's why we're all here

  2. #242

    Default

    Cheers for the reply b2bde4.
    I read Ted's blog post some while ago, and read it again yesterday before reaching this thread.

    It took me HOURS to figure out exactly why the CHS was so important, and why 224/56 was 128k aligned.
    In the end I took a break for 20 minutes with a friend, got back to it and it all just clicked .

    I think today my mission is to search the man pages to see how I set the filesystem block size.. That way I can make sure (and also experiment) of the sizes when I get my Vertex (or 'both' of them - one for each laptop).
    I'll try and post some test results of both best case (new) and worst case (filled disk) scenario's, since I think both are important to guage the performance of settings over time.

    Your suggestion won't work because it would only represent the worst case scenario. During normal operation the disk would slowly fill up over time. The time it takes for the disk to fill up depends on the usage pattern. During normal operation, not every write operation writes to a completely new block. Most writes probably translates to a re-write of an 'old' block.
    I remember reading that wear levelling will try to prefer overwriting a new block / less used block, rather than overwrite the same block.
    IMO, wear levelling leans more towards creating this scenario than preventing it, since it is trying to even out the erase count, rather than keep it to the same area.
    If this is the case, than you will encounter it simply over time, and not depend on 'fill' rates.
    Although the TRIM command obviously will change this (a block will be erased *hopefully* before a write command comes along).
    But yes, I am considering "worst case" - which is regular usage over a period of time.

    Anandtech did a very similar test in Windows-Land, and the Vertex ended up loosing about 14% performance (linky: http://www.anandtech.com/storage/sho...spx?i=3531&p=1 ).
    Be warned, it's a VERY lengthy post, and they do numerous tests which show different aspects of the drives (and this has actually persuaded me to get 2 Vertex drives).
    I just want to see how much the alignment and stripe size also effect degradation (since on a spanking new drive it doesn't effect performance all that much).

    OH, and a note to the previous LUKS post - I did find out about setting the block size.
    Seems you can do so while setting up the initial block device (not sure if you can change it - but my guess would be no, or possibly to make the blocks smaller only) using cryptsetup.
    The parameter is: --align-payload=1024
    This is because the value is multiplied by a 512-byte sector size (giving 512k... right?).
    .. There's also the ability to "offset" the start in the block device (so even if you're created the partition incorrectly, you can start the encrypted area at the correct alignment).
    I will have to have a look to see how large the metadata (or header or whatever) for LUKS is, because we don't want it being 256K and then the filesystem starting in the middle of an erase block... D'OH!

  3. #243
    OCZ Tweaker b2bde4's Avatar Flag of Sweden
    Join Date
    Mar 2009
    Posts
    271
    Mobo: (ASUS) AMD 780G + SB700
    CPU: AMD 4850e
    RAM: 4GB
    Vid: Passive ATI 2600XT
    PSU: 620W
    HDD: Vertex 30GB, FW 1.5
    OS: Ubuntu (10.04)

    Default

    Quote Originally Posted by Paul_one View Post
    I remember reading that wear levelling will try to prefer overwriting a new block / less used block, rather than overwrite the same block.
    IMO, wear levelling leans more towards creating this scenario than preventing it, since it is trying to even out the erase count, rather than keep it to the same area.
    If this is the case, than you will encounter it simply over time, and not depend on 'fill' rates.
    Quick note...because wear levelling is happening inside the disk, it's able to trim itself. Every time it decides to move a block to a new location it's able to trim the previous location.

    This is how the communication might work:
    Code:
    Operating System <-|-> SSD
    File System <-|-> lookup table <-> flash chip

    This is a generalized example:
    Code:
    Lookup table size: 0
    File System writes to SSD.
    SSD creates a new reference in lookup table pointing to flash chip.
    SSD follows reference and writes data.
    Lookup table size: 1
    File System makes changes to previous block.
    SSD wear levelling algorithm kicks in.
    SSD follows reference and copy content to buffer.
    SSD updates content in buffer with changes.
    SSD writes content to a new block.
    SSD updates reference in lookup table to point to the new position.
    Lookup table size: 1
    File System writes to a new position.
    SSD creates a new reference in lookup table pointing to flash chip.
    SSD follows reference and writes data.
    Lookup table size: 2
    When the lookup table contains one reference for each sector things will slow down. Without TRIM, it's not possible for the file system to clear data from the lookup table.

  4. #244

    Default

    Thanks.

    I was wondering why SSD's with "smart wear levelling" would choose to use "erase on write" rather than "erase on move".
    Performance would still go down, and still be effected by the block sizes of the filesystem - but not to the degree of my "worst case scenario" - which is a device which is almost 100&#37; full.

    Good example.

  5. #245
    OCZ User Flag of United States
    Join Date
    Apr 2009
    Posts
    8
    Mobo: MacBook (13-inch Late 2007) aka MacBook3,1
    CPU: 2GHz Intel Core 2 Duo
    RAM: 4GB
    OS: OSX 10.5.7

    Default

    hi, mark.

    thanks for chiming in

    Quote Originally Posted by mlord1 View Post
    we're still waiting for updated firmware from Indilinx with real TRIM support.
    have you been given any indication on when new firmware may become available?

    cheers,
    marc

  6. #246
    the Linux hdparm guy Flag of Canada
    Join Date
    Apr 2009
    Posts
    265
    Mobo: Inspiron 9400
    BIOS: A09
    CPU: T7400
    RAM: 3GB
    Vid: X1400
    HDD: Vertex 120GB
    OS: Linux

    Default

    Quote Originally Posted by beej View Post
    have you been given any indication on when new firmware may become available?
    Nope. Firmware 1571_OCZ is currently in pre-release at OCZ, and likely will appear for download on Tuesday. But the rumour is that it does not have a real TRIM opcode yet.

    Cheers

  7. #247
    OCZ Convert Sal's Avatar Flag of United States
    Join Date
    Apr 2009
    Location
    Chicago
    Posts
    189
    Mobo: Gigabyte EP45-UD3P
    BIOS: Award, F9 FW
    CPU: Intel Core2 Quad Q9550
    RAM: OCZ2RPR10664GK Reaper HPC 4x2GB
    Vid: EVGA GeForce 9800GT
    PSU: OCZ GameXStream 700W
    HDD: OCZ Vertex 60GB 1.41b FW, 2x Western Digital Caviar Black 500GB
    OS: PCLinuxOS

    Default

    Quote Originally Posted by mlord1 View Post
    Nope. Firmware 1571_OCZ is currently in pre-release at OCZ, and likely will appear for download on Tuesday. But the rumour is that it does not have a real TRIM opcode yet.

    Cheers
    So that means no trim code for hdparm this time around?
    Sal

  8. #248
    the Linux hdparm guy Flag of Canada
    Join Date
    Apr 2009
    Posts
    265
    Mobo: Inspiron 9400
    BIOS: A09
    CPU: T7400
    RAM: 3GB
    Vid: X1400
    HDD: Vertex 120GB
    OS: Linux

    Default

    Quote Originally Posted by Sal View Post
    So that means no trim code for hdparm this time around?
    Well, I might release hdparm with TRIM regardless, but the OCZ drives do not (yet) implement TRIM. I think a different 3-letter company is going to be first to market with that.

    -ml

  9. #249
    OCZ Convert Sal's Avatar Flag of United States
    Join Date
    Apr 2009
    Location
    Chicago
    Posts
    189
    Mobo: Gigabyte EP45-UD3P
    BIOS: Award, F9 FW
    CPU: Intel Core2 Quad Q9550
    RAM: OCZ2RPR10664GK Reaper HPC 4x2GB
    Vid: EVGA GeForce 9800GT
    PSU: OCZ GameXStream 700W
    HDD: OCZ Vertex 60GB 1.41b FW, 2x Western Digital Caviar Black 500GB
    OS: PCLinuxOS

    Default

    Quote Originally Posted by mlord1 View Post
    Well, I might release hdparm with TRIM regardless, but the OCZ drives do not (yet) implement TRIM. I think a different 3-letter company is going to be first to market with that.

    -ml
    Thanks Mark.
    This whole thing has got me a bit confused now. From what I've read even the upcoming fw release doesn't support the (proprietary) Win7 TRIM correctly. Neither does it support the current open ATA beta standard, hence you can't write a working code for hdparm.
    What is the TRIM support code in the fw, is it just a proprietary code to support the wiper tool for now?
    TIA
    Sal

  10. #250
    the Linux hdparm guy Flag of Canada
    Join Date
    Apr 2009
    Posts
    265
    Mobo: Inspiron 9400
    BIOS: A09
    CPU: T7400
    RAM: 3GB
    Vid: X1400
    HDD: Vertex 120GB
    OS: Linux

    Default

    Quote Originally Posted by Sal View Post
    What is the TRIM support code in the fw, is it just a proprietary code to support the wiper tool for now?
    It appears to be some proprietary hack, unique to Indilinx. The current drives are *not* ATA compliant at all -- in fact they violate ATA by reporting TRIM support despite not implementing it correctly. That's a definite no-no, and quite a black-eye for Indilinx and OCZ.

    Cheers

  11. #251
    OCZ Convert Sal's Avatar Flag of United States
    Join Date
    Apr 2009
    Location
    Chicago
    Posts
    189
    Mobo: Gigabyte EP45-UD3P
    BIOS: Award, F9 FW
    CPU: Intel Core2 Quad Q9550
    RAM: OCZ2RPR10664GK Reaper HPC 4x2GB
    Vid: EVGA GeForce 9800GT
    PSU: OCZ GameXStream 700W
    HDD: OCZ Vertex 60GB 1.41b FW, 2x Western Digital Caviar Black 500GB
    OS: PCLinuxOS

    Default

    Quote Originally Posted by mlord1 View Post
    It appears to be some proprietary hack, unique to Indilinx. The current drives are *not* ATA compliant at all -- in fact they violate ATA by reporting TRIM support despite not implementing it correctly. That's a definite no-no, and quite a black-eye for Indilinx and OCZ.

    Cheers
    Bummer.
    Thanks for the info.
    Cheers,
    Sal

  12. #252
    Linux User Flag of United States
    Join Date
    Mar 2009
    Location
    Chicago
    Posts
    158
    Mobo: EP35C-DS3R
    CPU: Q6600
    RAM: 8G
    Vid: 7800GT
    PSU: Forgot
    HDD: 30G vertex
    OS: Ubuntu 9.04 x86_64

    Default

    Hey guys if anyone needs a guide for getting alignment with LUKS working, I got it working last weekend. I will write something up in the next couple days....In ubuntu 9.04 (my oS) there is a BUG (and probably in debian and some of the other linux distros) with the initrd cryptroot script that does not honor the offset parameter. I have written a patch/fix for it.

  13. #253
    OCZ User Flag of Canada
    Join Date
    May 2009
    Posts
    12
    Mobo: Apple MacBook 3,1
    OS: OS X Leopard 10.5.7

    Default

    Please post it Robstarusa because I was planning to use the align-payload.

    Though, Arch Linux which is my plan, uses initramfs not initrd so that's good.. I wonder if that means it doesn't have the bug as it's technically different.

    Also remember guys, if you don't want to have a gazillion different crypted partitions each set up one by one, your life will be easier if you just dmcrypt the entire drive except for /boot, and then put LVM on top of that, and in LVM make your normal stuff. That way you only need 1 password.

  14. #254
    OCZ Tweaker b2bde4's Avatar Flag of Sweden
    Join Date
    Mar 2009
    Posts
    271
    Mobo: (ASUS) AMD 780G + SB700
    CPU: AMD 4850e
    RAM: 4GB
    Vid: Passive ATI 2600XT
    PSU: 620W
    HDD: Vertex 30GB, FW 1.5
    OS: Ubuntu (10.04)

    Default

    Having some spare time to waste...

    Bash scrip for benchmarking your SSD .
    Sequential read benchmark.
    Extracting text output from dd. Error if output differentiate.
    1. Save script to file [Example: test].
    2. Make executable.
    3. Run as root [sudo ./test /dev/sda]
    Code:
      Example: ./test [Path]
               ./test /dev/sda
      Example: ./test [Path] [Graph limit (${max_speed}MB/s)]
               ./test /dev/sda ${max_speed}
      Example: ./test [Path] [Graph limit (${max_speed}MB/s)] [Test file (${file_size}MB)]
               ./test /dev/sda $max_speed $file_size
    PHP Code:
    #!/bin/bash
    # Created by: b2bde4
    # Date (YYMMDD): 090609
    # Link name: Guide Linux - Tips, tweaks and alignment
    # Link: http://www.ocztechnologyforum.com/forum/showpost.php?p=396928&postcount=254

    # Number of bars in graph.
    bar_length=30
    # Graph limit in MB/s
    max_speed=300
    # Test block size in kB.
    block_table=( 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 )
    # Test file size in MB.
    file_size=100

    # n
    do_bar ()
    {
      echo -
    [
      
      for (( 
    i=0i<$&& i<bar_lengthi++)); do
        echo -
    =
      
    done
      
      
    for (( ii<bar_lengthi++)); do
        echo -
    " "
      
    done
      
      
    echo -]
    }

    # speed, block_size
    do_print ()
    {
      
    a=$(( $$bar_length $max_speed ))
      
    printf "%8s" "[${2}kB]"
      
    do_bar $a
      
    echo "[${1}MB/s]"
    }

    # path, block_size
    do_test ()

      
    count=$(( $file_size 1024 / $))
      
      var=$(
    dd conv=nocreat iflag=direct if=$1 of=/dev/null bs=${2}k count=$count 2>&1)
      
      
    start=-1;
      
      while [ 
    "${var: $start : 1}" != " " ]
      do
        
    start=$(( $start-))
      
    done
      
      start
    =$(( $start-))
      
    stop=$start;
      
      while [ 
    "${var: $start : 1 }" != " " ]
      do
        if [ ${var: 
    $start } == "," ] || [ ${var: $start } == "." ]
        
    then
          stop
    =$(( $start-))
        
    fi
        start
    =$(( $start-))
      
    done
      
      start
    =$(( $start+))
      
      return ${var: 
    $start : $(( $stop $start ))}
    }

    # Main.

    if [ ! $]
      
    then
      
    echo "Example: $0 [Path]"
      
    echo "         $0 /dev/sda"
      
    echo "Example: $0 [Path] [Graph limit (${max_speed}MB/s)]"
      
    echo "         $0 /dev/sda ${max_speed}"
      
    echo "Example: $0 [Path] [Graph limit (${max_speed}MB/s)] [Test file (${file_size}MB)]"
      
    echo "         $0 /dev/sda $max_speed $file_size"
      
    exit
    fi

    if [ $]
      
    then
      max_speed
    =$2
    fi

    if [ $]
      
    then
      file_size
    =$3
    fi

    echo "[block_size][%][read_speed]"
    echo "Graph limit: ${max_speed}MB/s"
    echo "Test file: ${file_size}MB"
    echo ""

    #printf "%9s%${bar_length}s\n" "0" "${max_speed}MB/s"

    for i in ${block_table[@]}; do
      
    do_test $1 $i
      do_print 
    $? $i
    done 
    Last edited by b2bde4; 06-08-2009 at 02:39 PM.

  15. #255
    OCZ Tweaker b2bde4's Avatar Flag of Sweden
    Join Date
    Mar 2009
    Posts
    271
    Mobo: (ASUS) AMD 780G + SB700
    CPU: AMD 4850e
    RAM: 4GB
    Vid: Passive ATI 2600XT
    PSU: 620W
    HDD: Vertex 30GB, FW 1.5
    OS: Ubuntu (10.04)

    Default

    These are my results with 30GB Vertex, FW 1199

    Code:
    [block_size][%][read_speed]
    Graph limit: 300MB/s
    Test file: 100MB
    
       [2kB][==                            ][26MB/s]
       [4kB][====                          ][45MB/s]
       [8kB][======                        ][68MB/s]
      [16kB][=========                     ][94MB/s]
      [32kB][==============                ][142MB/s]
      [64kB][==================            ][180MB/s]
     [128kB][==================            ][182MB/s]
     [256kB][===================           ][193MB/s]
     [512kB][====================          ][201MB/s]
    [1024kB][====================          ][201MB/s]
    [2048kB][====================          ][201MB/s]
    [4096kB][====================          ][201MB/s]
    [8192kB][====================          ][200MB/s]

+ Reply to Thread
Page 17 of 23 FirstFirst ... 7 15 16 17 18 19 ... LastLast

Tags for this Thread

Bookmarks

Posting Permissions

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