Announcement

Collapse
No announcement yet.

RapidDisk, A New Linux RAM Disk Kernel Module

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • RapidDisk, A New Linux RAM Disk Kernel Module

    Phoronix: RapidDisk, A New Linux RAM Disk Kernel Module

    Released last month was RapidDisk 1.0, which is a Linux kernel module that up to this point has received little attention on the Internet. RapidDisk is a new Linux RAM disk kernel module like the brd and zram modules, but with a different feature-set...

    http://www.phoronix.com/vr.php?view=OTc0Ng

  • #2
    From his wiki:
    $ sudo dd if=/dev/zero of=/mnt/test/test.dat bs=4K count=262144
    1054507008 bytes (1.1 GB) copied, 3.24306 s, 325 MB/s
    Also, all other Linux implementations of RAM disks exist as file systems in memory. These include tmpfs and ramfs. These file systems are not always the most ideal solution to achieving high performance.
    So I thought I'd compare to tmpfs. Not sure what CPU/Ram he used in his benchmarks, but it's probably faster than my 3 year old Athlon 64 X2 5000+.

    ~> dd if=/dev/zero of=/tmp/zero.dat bs=8K count=32768
    268435456 bytes (268 MB) copied, 0.266542 s, 1.0 GB/s
    what?

    Either he has choosen poor benchmarks, a poor machine to run the benchmarks on, or he wasn't really clear about the advantages. I'm also wondering why my ram is specified for a throughput of >5G/sec..

    Comment


    • #3
      Originally posted by rohcQaH View Post
      From his wiki:


      So I thought I'd compare to tmpfs. Not sure what CPU/Ram he used in his benchmarks, but it's probably faster than my 3 year old Athlon 64 X2 5000+.


      what?

      Either he has choosen poor benchmarks, a poor machine to run the benchmarks on, or he wasn't really clear about the advantages. I'm also wondering why my ram is specified for a throughput of >5G/sec..
      Your block size is different though. Using 4K blocks you would have to do many more transfers.

      As always, you will have to bench both on the same machine, under the same conditions, to get meaningful results.

      Comment


      • #4
        o@a:/tmp$ sudo dd if=/dev/zero of=/tmp/test.dat bs=4K count=222144
        222144+0 records in
        222144+0 records out
        909901824 bytes (910 MB) copied, 1,89587 s, 480 MB/s
        o@a:/tmp$ sudo dd if=/dev/zero of=/tmp/test.dat bs=8K count=112144
        112144+0 records in
        112144+0 records out
        918683648 bytes (919 MB) copied, 1,81037 s, 507 MB/s


        This was run on an IBM T42 with 2G of ram (1G tmpfs). Now this baby is almost 7 years old (i supprised myself with its age there, but is still works perfectly well for me) and I outperform his test...

        Comment


        • #5
          Thank you for your interest...

          I was pleasantly surprised to find this posted on Phoronix earlier this morning. I had noticed that the original article made a slight error:
          RapidDisk can handle dynamically adding or removing RAM-based block devices of varying sizes, LZO data compression (still being implemented), and SHA-256-based error-correction.
          All of these features are on the roadmap and not yet implemented. I am currently working on the LZO compression. I just need to finish the decompression portion of the code. As for the benchmarks...

          I did update the wiki with the following:
          These numbers were obtained using an older 32-bit system. Better results will be obtained with the latest and greatest of hardware especially on 64-bit architectures.
          I was impressed to see a throughput of 1GB/s...that is awesome! If you feel that I need to update the benchmarks and if you have the hardware to run them on, I would be more than thrilled to post them. Please do not hesitate to contact me. More information on contribution to the project can be found at: http://wiki.petroskoutoupis.com/inde...y_Contribution

          Again, I am extremely excited to see that there is an interest here.

          Comment


          • #6
            This won't kill anything, will it? Pretty sure its required.. as blk_queue_ordered was depreciated.. I'm extremely noobish with programming.. extremely extremely.. but I know how to use a search engine and this is the solution I came up with to fix my compile errors... This is on 3.1.0-rc1+

            @@ -461,7 +461,7 @@ attach_device(int num, int size){
            goto out_free_dev;
            blk_queue_make_request(rxdsk->rxdsk_queue, rxdsk_make_request);
            blk_queue_logical_block_size (rxdsk->rxdsk_queue, BYTES_PER_SECTOR);
            - blk_queue_ordered(rxdsk->rxdsk_queue, QUEUE_ORDERED_TAG, NULL);
            + blk_queue_flush(rxdsk->rxdsk_queue, REQ_FLUSH);

            if (!(disk = rxdsk->rxdsk_disk = alloc_disk (1)))
            goto out_free_queue;

            Comment

            Working...
            X