Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 47

Thread: EXT3, EXT4, Btrfs Ubuntu Netbook Benchmarks

  1. #21
    Join Date
    Jul 2009
    Posts
    416

    Default

    Quote Originally Posted by BlackStar View Post
    Interesting comparison. I wonder what the upgrade path from ext4 to btrfs will look like: backup, format, restore? A quick search doesn't bring up anything.
    What I did was put my entire / into a tarball, put that on a large external hard drive, format, and untar.

    If you're kind of limited on storage space, I'd recommend the xz compressed tarball. I compressed my ~35gb filesystem to 13gb.

    Have a look at this Gentoo wiki page: http://en.gentoo-wiki.com/wiki/Custom_Stage4

    It says to exclude /dev from the tarball, but if you do that, remember to copy /dev/null, /dev/zero, and /dev/tty1 from a LiveCD or whatever. Otherwise udev is going to have some major problems. And use -a option on cp. You might just be better off including /dev.

    And you can safely ignore a lot of the article, it's mostly for moving a filesystem to a different machine and not so much backup and restore.

  2. #22
    Join Date
    Oct 2007
    Posts
    27

    Default

    Quote Originally Posted by pvtcupcakes View Post
    What I did was put my entire / into a tarball, put that on a large external hard drive, format, and untar.

    If you're kind of limited on storage space, I'd recommend the xz compressed tarball. I compressed my ~35gb filesystem to 13gb.

    Have a look at this Gentoo wiki page: http://en.gentoo-wiki.com/wiki/Custom_Stage4

    It says to exclude /dev from the tarball, but if you do that, remember to copy /dev/null, /dev/zero, and /dev/tty1 from a LiveCD or whatever. Otherwise udev is going to have some major problems. And use -a option on cp. You might just be better off including /dev.

    And you can safely ignore a lot of the article, it's mostly for moving a filesystem to a different machine and not so much backup and restore.
    Its really too bad more people aren't finding the wiki:

    http://btrfs.wiki.kernel.org/index.p...sion_from_Ext3

    # Always run fsck first
    fsck.ext3 -f /dev/xxx

    # Convert from Ext3/4->Btrfs
    btrfs-convert /dev/xxx

    # Mount the resulting Btrfs filesystem
    mount -t btrfs /dev/xxx /btrfs

  3. #23
    Join Date
    Feb 2010
    Location
    Sweden
    Posts
    58

    Default

    The SQLite test is really interesting from a programmers view since it represents the very worst usage case of SQLite. If you have lots of inserts like this you should perform them inside a transaction.

    I downloaded and performed the test on my local EXT4 machine with and without transactions:

    without (as in the benchmark): 27 inserts per second
    with transactions: 24558 inserts per second

    Sadly I have no EXT3 partition, it would be interesting to see whether EXT3 would enjoy the very same performance gain since it shows less MBps capability than EXT4 or Btrfs.

    Still it is a very good benchmark since it really shows the number of possible transactions per second, but one does wonder if EXT3 really performs true transactions since it has a so much higher number.

  4. #24
    Join Date
    Jun 2008
    Posts
    197

    Default

    I hope when doing certain tests (like unpacking the kernel) the output is directed to /dev/null because any variations in performance between distros can be attributed to the 2D performance of the graphics drivers.

  5. #25
    Join Date
    Jun 2006
    Posts
    31

    Default

    Some of the results look really fishy. How are you accounting for files being cached in memory by the kernel? It seems you should do a cold boot with swap disabled before each test, and make sure the files being tested are not accessed in any way before the test is run.

    In real life files will be cached, and you want your file system to work effectively with cache. So there should be cached results too, where obviously the data set is larger than the largest possible cache.

  6. #26
    Join Date
    Jun 2006
    Posts
    311

    Default

    Quote Originally Posted by Jimbo View Post
    "while Ubuntu 10.04 is using Linux 2.6.32"

    For BTRFS it should be nice to test it with its latest code, or at least with 2.6.33-rc8. It's an experimental FS so its important to see its latest improvements. As always phoronix is too ubuntu focus.

    Anyway good article, and WOW!! nice BTRFS perfomance!, a compressed btrfs partition results should be interesting to see too!!

    Regards
    The intent of the benchmarking was to compare the Ubuntu supported filesystems. If Ubuntu was planning to pick up bleeding edge FS code from upstream, then it would have been covered.

    The benchmark is intended to allow people to understand the impact of choosing one filesystem over another. It provide quantitative data rather than a qualitative FS A is WAY faster than FS B. You've got the information to make a judgment when you install a karmic or lucd build and are asked to choose your FS. Once installed (at installation time), most people don't change their FS.

  7. #27
    Join Date
    Jun 2006
    Posts
    311

    Default

    Quote Originally Posted by devius View Post
    I find these filesystem comparisions interesting, yet I think they lose some value by only including a type of storage. I don't even know if there are differences in the way filesystems work with SSDs and HDDs, so what I would like is some clarification on this matter. Maybe there are some filesystems that are more suited for SDDs and others for HDDs?
    Number one rule of comparisons. Change one variable and one variable only. In this case the FS was changed. The next dimension to hit is to change the HDD technology. But which FS do you use for all the tests? Running them all yields too many test passes. These results allow you to go the next dimension after you choose the FS that best supports your workload.

  8. #28
    Join Date
    Jun 2006
    Posts
    311

    Default

    Quote Originally Posted by RussDill View Post
    Timing things like

    git fast-import
    git add/commit
    git checkout <branch>
    git gc

    With a test repo.
    Create a PTS test case and provide it to Michael. I am sure he'll include it. Just make sure it is relevant and measures what you are wanting it to measure. (This means writing a textual paragraph covering what you are actually testing).

  9. #29
    Join Date
    Jun 2006
    Posts
    311

    Default

    Quote Originally Posted by F.Ultra View Post
    The SQLite test is really interesting from a programmers view since it represents the very worst usage case of SQLite. If you have lots of inserts like this you should perform them inside a transaction.

    ...

    without (as in the benchmark): 27 inserts per second
    with transactions: 24558 inserts per second

    ...

    Still it is a very good benchmark since it really shows the number of possible transactions per second, but one does wonder if EXT3 really performs true transactions since it has a so much higher number.
    The SQLite test as it stands is *very* sensitive to the fsync/fdatasync. You can tune the test to demonstrate database performance, but it currently isn't intended to do that. The intent of the test is to show the FS performance, and to simulate some contrived situations where people can't do transactions (like a busy 2-tier PHP site. The 3rd tier allows you to aggregate transactions, but a 2-tier won't)..

    In most cases where there is a large delta, it has been shown that the "faster" FS has either traded performance for data integrity or have thrown out integrity altogether (there was a KVM/QEMU bug that mean a sync file operation would end up being async. The guest running under KVM was about 100 times faster than the host for the SQLITE test. As it turns out the fsync in the KVM, wasn't really an fsync to the physical disk anyway.

  10. #30
    Join Date
    Nov 2008
    Posts
    118

    Default typo

    On page 3:
    Code:
    When doubling the write size in IOzone to 8GB, EXT4 and Btrfs continued to operate much faster than EXT4.
    I think there's an EXT3 missing somewhere.

Posting Permissions

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