RE: lvm partition on ramdisk

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks for the update. I have not followed the thread closely… did you see any significant measured peformance increase in using lvm on a ramdisk?

 

Regards

 


From: linux-lvm-bounces@redhat.com [mailto:linux-lvm-bounces@redhat.com] On Behalf Of Larry Dickson
Sent: 19 May 2008 15:37
To: LVM general discussion and development
Subject: Re: lvm partition on ramdisk

 

Final results FYI in this investigation: A recent Ubuntu release gets past the 1TB limit. I found binaries for dosfstools_2.11-2.1ubuntu3 at
 
http://packages.ubuntu.com/feisty/otherosfs/dosfstools
 
and unpacked them with ar -x. The source is in
 
https://launchpad.net/ubuntu/+source/dosfstools/2.11-2.1ubuntu3
 

With 4KB sectors, it defaults to 128KB clusters and reaches over 97% write speed on an 8TB volume. The ramdisk area needed is a little over 512MB, so if you use 768MB you get quite a bit of room for directories also on ramdisk, and with a little finesse you can even make the subdirectories lay themselves down on ramdisk. To be "Windows-legal" you could use 32KB clusters and a little over 2GB ramdisk (or a little over 1GB with one FAT). Linux is happy with the big clusters, and according to the design should actually be willing to go to 16TB.

Larry

 

On 5/13/08, Stuart D. Gathman <stuart@bmsi.com> wrote:

On Tue, 13 May 2008, Larry Dickson wrote:

> on the full, unpartitioned lv. Then it mounted, with the entire FAT on
> ramdisk, and wrote very fast because FAT32 (like DOS) lays down data in
> order from the start of a disk and does not skip around (I'd be interested
> if anyone knows any other file systems with that property).

The SysV filesystem put a fixed size inode table at the beginning of a
partition.  More modern filesystems from ext to reiser try to distribute
the meta-data to keep it closer to the data.  This is, of course, counter
productive when the beginning of a disk is significantly faster and seek-free
as in your setup.

Since ext3 inode placement is table driven (with the table in a magic inode),
there is probably a simple patch to mke2fs to create only one inode table at
the beginning of a drive.  In fact, I wonder if there is already an option...
looks like -g blocks_per_group might do the trick - assuming inodes are
at the beginning of a block group, rather than the middle.  If not,
a patch to mke2fs is needed to do what you want.

--
             Stuart D. Gathman <stuart@bmsi.com>
   Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

 

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux