Re: [PATCH 01/16 v5] pramfs: documentation

[Marco Stornelli]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/