lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A3E6F28.4090404@gmail.com>
Date:	Sun, 21 Jun 2009 19:34:32 +0200
From:	Marco <marco.stornelli@...il.com>
To:	Pavel Machek <pavel@....cz>
CC:	Jamie Lokier <jamie@...reable.org>,
	Linux Embedded <linux-embedded@...r.kernel.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	Daniel Walker <dwalker@....ucsc.edu>
Subject: Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem

Pavel Machek wrote:
>>> Why is an entire filesystem needed, instead of simply a block driver
>>> if the ramdisk driver cannot be used?
>>>
>> >From documentation:
>>
>> "A relatively straight-forward solution is to write a simple block
>> driver for the non-volatile RAM, and mount over it any disk-based
>> filesystem such as ext2/ext3, reiserfs, etc.
>>
>> But the disk-based fs over non-volatile RAM block driver approach has
>> some drawbacks:
>>
>> 1. Disk-based filesystems such as ext2/ext3 were designed for optimum
>>    performance on spinning disk media, so they implement features such
>>    as block groups, which attempts to group inode data into a contiguous
>>    set of data blocks to minimize disk seeking when accessing files. For
>>    RAM there is no such concern; a file's data blocks can be scattered
>>    throughout the media with no access speed penalty at all. So block
>>    groups in a filesystem mounted over RAM just adds unnecessary
>>    complexity. A better approach is to use a filesystem specifically
>>    tailored to RAM media which does away with these disk-based features.
>>    This increases the efficient use of space on the media, i.e. more
>>    space is dedicated to actual file data storage and less to meta-data
>>    needed to maintain that file data.
> 
> So... what is the performance difference between ext2 and your new
> filesystem?
> 

About the "space" you can read a detailed documentation on the site:

http://pramfs.sourceforge.net/pramfs-spec.html

In addition I can do an example of "compact" information: ext2 uses
directory entry objects ("dentries") to associate file names to inodes,
and these dentries are located in data blocks owned by the parent
directory. In pramfs, directory inode's do not need to own any data
blocks, because all dentry information is contained within the inode's
themselves.

>From performance point of view:

Sometimes ago I uploaded here (http://elinux.org/Pram_Fs) some benchmark
results to compare the performance with and without XIP in a real
embedded environment with bonnie++. You could use it as reference point.

I hope I've answered to your question.

Regards,

Marco

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ