[linux-lvm] lvm partition on ramdisk

[Larry Dickson]

The purpose was to move seeking operations onto the ramdisk (ultimately
NVRAM or battery-backed), and use a file system that allocates disk sectors
in sequential order for scientific (no-delete) data streaming writes. It
allows near full speed writing to the main (big RAID) storage, and yet a
standard file system structure appears on the recorded data at little cost.
Log-structured file systems serve a similar purpose, but the structure of
the data and metadata is quite complex, and an additional step of "capping"
is needed if random-access reads are to be reasonably fast.

Larry

On 5/19/08, Gerrard Geldenhuis <Gerrard.Geldenhuis at datacash.com> wrote:
>
>  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 at redhat.com [mailto:linux-lvm-bounces at redhat.com]
> *On Behalf Of *Larry Dickson
> *Sent:* 19 May 2008 15:37
> *To:* LVM general discussion and development
> *Subject:* Re: [linux-lvm] 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 at 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 at 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 at 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20080519/83dd1b36/attachment.htm>