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: <20090621205245.GC3254@elf.ucw.cz>
Date:	Sun, 21 Jun 2009 22:52:45 +0200
From:	Pavel Machek <pavel@....cz>
To:	Marco <marco.stornelli@...il.com>
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


> >> 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

I do not see any numbers there. Do you think you can save significant
memory when storing for example kernel source trees?

> In addition I can do an example of "compact" information: ext2 uses
> directory entry objects ("dentries") to associate file names to
> inodes,

I'm not sure that on-disk directory entry == dentry.

> 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.

How do you handle hard-links, then?

> >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.

Well, so XIP helps. ext2 can do XIP too, IIRC. Is your performance
better than ext2?

Wait... those numbers you pointed me... claim to be as slow as
13MB/sec. That's very very bad. My harddrive is faster than that.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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