linux-kernel - Re: [PATCH 01/16 v5] pramfs: documentation

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] [day] [month] [year] [list]

Message-ID: <4D219CD4.1070307@gmail.com>
Date:	Mon, 03 Jan 2011 10:54:28 +0100
From:	Marco Stornelli <marco.stornelli@...il.com>
To:	Pavel Machek <pavel@....cz>
CC:	Linux Kernel <linux-kernel@...r.kernel.org>,
	Linux Embedded <linux-embedded@...r.kernel.org>,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	Tim Bird <tim.bird@...sony.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 01/16 v5] pramfs: documentation

Il 03/01/2011 08:45, Pavel Machek ha scritto:
> Hi!
> 
>> +But the disk-based fs over non-volatile RAM block driver approach has
>> +some drawbacks:
>> +
>> +1. Complexity of disk-based fs: disk-based filesystems such as ext2/ext3/ext4
>> +   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
> 
> Yes, and they are also used on 99% of machines out there -> well
> debugged.

I know that you aren't a supporter for this kind of project...do you
mean that the world finishes with ext4? Why do you ask for removing from
mainline logfs, nilfs, btrs and so on? At the end all can use ext4
everywhere and in all situations, other fs are crap. In addition, I
really don't want to replace extN fs or say "my fs is absolute better of
extN", I'm pointing out that a simpler and ad-hoc solution for *this use
case* maybe it's better.

> 
> Is there fsck for pramfs available, for example?
> 

Currently not. First of all there isn't a device sdX to use, I could use
mem but it's not always available when you use strict_devmem option
because the memory region is marked "exclusive" (it's used to avoid to
"play" with that memory region). In addition, since the simplicity and
the scope of this fs I didn't find an use case that justifies writing an
fsck.

>> +   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... how big is overhead of pramfs compared to ext2?

You can find a lot of information on the tech web site page.

> 
> Can pramfs handle powerdown at arbitrary time?
> 

If you are asking for journaling, the answer is currently not. Adding
journaling means a deeply rework and redesing. This effort can be
justified only with high benefits. At the moment for the scope of this
fs I didn't find them. I recall that we are not talking about replace an
fs like ext4 for a desktop rootfs, but only to have a place to write not
sensible and temporary information in an embedded system. There are
other example of this kind as the pmem driver written by Google guys (it
was in the staging tree) or the "persistent store" written by Tony Luck.
The idea here is to provide a classic fs interface to that memory area.

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/