[PATCH 00/17] pramfs: persistent and protected RAM filesystem

[PATCH 00/17] pramfs: persistent and protected RAM filesystem

[Marco Stornelli]

Hi all,

after several reviews is time to submit the code for mainline. Thanks to
CELF to believe and support actively the project and thanks to Tim Bird.

Here the stats:

 Documentation/filesystems/pramfs.txt |  179 ++++++
 Documentation/filesystems/xip.txt    |    2 +
 arch/Kconfig                         |    3 +
 arch/x86/Kconfig                     |    1 +
 fs/Kconfig                           |    8 +-
 fs/Makefile                          |    1 +
 fs/pramfs/Kconfig                    |   72 +++
 fs/pramfs/Makefile                   |   14 +
 fs/pramfs/acl.c                      |  433 +++++++++++++
 fs/pramfs/acl.h                      |   86 +++
 fs/pramfs/balloc.c                   |  147 +++++
 fs/pramfs/desctree.c                 |  181 ++++++
 fs/pramfs/desctree.h                 |   44 ++
 fs/pramfs/dir.c                      |  208 +++++++
 fs/pramfs/file.c                     |  326 ++++++++++
 fs/pramfs/inode.c                    |  848 ++++++++++++++++++++++++++
 fs/pramfs/ioctl.c                    |  121 ++++
 fs/pramfs/namei.c                    |  371 ++++++++++++
 fs/pramfs/pram.h                     |  269 +++++++++
 fs/pramfs/pramfs_test.c              |   47 ++
 fs/pramfs/super.c                    |  940 +++++++++++++++++++++++++++++
 fs/pramfs/symlink.c                  |   76 +++
 fs/pramfs/wprotect.c                 |   41 ++
 fs/pramfs/wprotect.h                 |  151 +++++
 fs/pramfs/xattr.c                    | 1104 ++++++++++++++++++++++++++++++++++
 fs/pramfs/xattr.h                    |  131 ++++
 fs/pramfs/xattr_security.c           |   78 +++
 fs/pramfs/xattr_trusted.c            |   65 ++
 fs/pramfs/xattr_user.c               |   68 +++
 fs/pramfs/xip.c                      |   83 +++
 fs/pramfs/xip.h                      |   28 +
 include/linux/magic.h                |    1 +
 include/linux/pram_fs.h              |  130 ++++
 include/linux/pram_fs_sb.h           |   45 ++
 34 files changed, 6299 insertions(+), 3 deletions(-)


Marco 

Re: [PATCH 00/17] pramfs: persistent and protected RAM filesystem

[Peter Zijlstra]

On Thu, 2011-01-06 at 13:00 +0100, Marco Stornelli wrote:
> Hi all,
> 
> after several reviews is time to submit the code for mainline. Thanks to
> CELF to believe and support actively the project and thanks to Tim Bird.

Tony Luck was also playing with something like this I believe.

Re: [PATCH 00/17] pramfs: persistent and protected RAM filesystem

[Marco Stornelli]

Il 06/01/2011 15:03, Peter Zijlstra ha scritto:
> On Thu, 2011-01-06 at 13:00 +0100, Marco Stornelli wrote:
>> Hi all,
>>
>> after several reviews is time to submit the code for mainline. Thanks to
>> CELF to believe and support actively the project and thanks to Tim Bird.
> 
> Tony Luck was also playing with something like this I believe.
> 

Yes, I know. Even if the approach is different. He is trying to use a
persistent space record-based and with a simple fs interface to store
oops or something like this. The idea here is a little bit different,
i.e. to have a place (a generic piece of memory) to write not sensible
and temporary information with a complete fs structure. However we are
on the same road :)

Marco

Re: [PATCH 00/17] pramfs: persistent and protected RAM filesystem

[Marco Stornelli]

Il 06/01/2011 17:26, Marco Stornelli ha scritto:
> Il 06/01/2011 15:03, Peter Zijlstra ha scritto:
> and temporary information with a complete fs structure. However we are
> 

Errata corrige: maybe I used the wrong term, I meant "volatile" instead
of "temporary" information, i.e. I'd like to save this info to re-read
it later but I don't want to store it in flash, a simple log, run-time
information for debug like a flight-recorder or whatever you want.

RE: [PATCH 00/17] pramfs: persistent and protected RAM filesystem

[Luck, Tony]

> Errata corrige: maybe I used the wrong term, I meant "volatile" instead
> of "temporary" information, i.e. I'd like to save this info to re-read
> it later but I don't want to store it in flash, a simple log, run-time
> information for debug like a flight-recorder or whatever you want.

I'm puzzled by the use of "a generic piece of memory" to store "persistent"
things (Perhaps this is made clear in the 17 parts of the patch? I haven't
read them yet).  On x86 f/w typically clears all of memory on reset ... so
you only get persistence if you use kexec to get from the old kernel to
the new one.

-Tony

Re: [PATCH 00/17] pramfs: persistent and protected RAM filesystem

[Marco Stornelli]

Il 06/01/2011 19:22, Luck, Tony ha scritto:
>> Errata corrige: maybe I used the wrong term, I meant "volatile" instead
>> of "temporary" information, i.e. I'd like to save this info to re-read
>> it later but I don't want to store it in flash, a simple log, run-time
>> information for debug like a flight-recorder or whatever you want.
> 
> I'm puzzled by the use of "a generic piece of memory" to store "persistent"
> things (Perhaps this is made clear in the 17 parts of the patch? I haven't
> read them yet).  On x86 f/w typically clears all of memory on reset ... so
> you only get persistence if you use kexec to get from the old kernel to
> the new one.
> 
> -Tony
> 

First of all, you can find a lot of information on the web site where
there is an overview and a page with implementation details, benchmark
and so on. With "a generic piece of memory" I mean a generic memory
device directly addressable. Usually this generic device is an NVRAM, so
we have a persistent store. If you haven't got this hw you can use other
devices or the classic RAM, in this case you have a fs persistent only
over reboot. The use of this fs is mainly for embedded systems, fw can
be configured to not clear *all* the memory. Pramfs is indeed supported
by U-Boot, you can see CONFIG_PRAM in the Das U-Boot manual. x86 in this
case can be a "strange" world for this fs, but however if the user wants
it can be used without problems because there aren't neither strict arch
or hw dependency.

Marco

Re: [PATCH 00/17] pramfs: persistent and protected RAM filesystem

[Pavel Machek]

> Il 06/01/2011 19:22, Luck, Tony ha scritto:
> >> Errata corrige: maybe I used the wrong term, I meant "volatile" instead
> >> of "temporary" information, i.e. I'd like to save this info to re-read
> >> it later but I don't want to store it in flash, a simple log, run-time
> >> information for debug like a flight-recorder or whatever you want.
> > 
> > I'm puzzled by the use of "a generic piece of memory" to store "persistent"
> > things (Perhaps this is made clear in the 17 parts of the patch? I haven't
> > read them yet).  On x86 f/w typically clears all of memory on reset ... so
> > you only get persistence if you use kexec to get from the old kernel to
> > the new one.
> > 
> > -Tony
> > 
> 
> First of all, you can find a lot of information on the web site where
> there is an overview and a page with implementation details, benchmark
> and so on. With "a generic piece of memory" I mean a generic memory
> device directly addressable. Usually this generic device is an NVRAM, so
> we have a persistent store. If you haven't got this hw you can use other
> devices or the classic RAM, in this case you have a fs persistent only
> over reboot. The use of this fs is mainly for embedded systems, fw can
> be configured to not clear *all* the memory. Pramfs is indeed supported
> by U-Boot, you can see CONFIG_PRAM in the Das U-Boot manual. x86 in this
> case can be a "strange" world for this fs, but however if the user wants
> it can be used without problems because there aren't neither strict arch
> or hw dependency.

Actually you probably want to state u-boot compatibility in the commit
message. AFAICT, that is quite good argument _for_ inclusion.


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 00/17] pramfs: persistent and protected RAM filesystem

[Marco Stornelli]

Hi all,

On 06/01/2011 13:00, Marco Stornelli wrote:
> Hi all,
> 
> after several reviews is time to submit the code for mainline. Thanks to
> CELF to believe and support actively the project and thanks to Tim Bird.
> 
> Here the stats:
> 
>  Documentation/filesystems/pramfs.txt |  179 ++++++
>  Documentation/filesystems/xip.txt    |    2 +
>  arch/Kconfig                         |    3 +
>  arch/x86/Kconfig                     |    1 +
>  fs/Kconfig                           |    8 +-
>  fs/Makefile                          |    1 +
>  fs/pramfs/Kconfig                    |   72 +++
>  fs/pramfs/Makefile                   |   14 +
>  fs/pramfs/acl.c                      |  433 +++++++++++++
>  fs/pramfs/acl.h                      |   86 +++
>  fs/pramfs/balloc.c                   |  147 +++++
>  fs/pramfs/desctree.c                 |  181 ++++++
>  fs/pramfs/desctree.h                 |   44 ++
>  fs/pramfs/dir.c                      |  208 +++++++
>  fs/pramfs/file.c                     |  326 ++++++++++
>  fs/pramfs/inode.c                    |  848 ++++++++++++++++++++++++++
>  fs/pramfs/ioctl.c                    |  121 ++++
>  fs/pramfs/namei.c                    |  371 ++++++++++++
>  fs/pramfs/pram.h                     |  269 +++++++++
>  fs/pramfs/pramfs_test.c              |   47 ++
>  fs/pramfs/super.c                    |  940 +++++++++++++++++++++++++++++
>  fs/pramfs/symlink.c                  |   76 +++
>  fs/pramfs/wprotect.c                 |   41 ++
>  fs/pramfs/wprotect.h                 |  151 +++++
>  fs/pramfs/xattr.c                    | 1104 ++++++++++++++++++++++++++++++++++
>  fs/pramfs/xattr.h                    |  131 ++++
>  fs/pramfs/xattr_security.c           |   78 +++
>  fs/pramfs/xattr_trusted.c            |   65 ++
>  fs/pramfs/xattr_user.c               |   68 +++
>  fs/pramfs/xip.c                      |   83 +++
>  fs/pramfs/xip.h                      |   28 +
>  include/linux/magic.h                |    1 +
>  include/linux/pram_fs.h              |  130 ++++
>  include/linux/pram_fs_sb.h           |   45 ++
>  34 files changed, 6299 insertions(+), 3 deletions(-)
> 

Can I have a feedback to insert this fs in the linux-next? From this
latest review I received some comments about how to fix some fs problems
on-the-fly without to clean all and restart. My next step will be to
write a simple fsck.pram to allow to fix these situations. However I
think the kernel code it's mature to be inserted in a pre-mainline
container. If I'll receive a positive feedback to my question, I'll
repost the patches to the last version (I updated the fs to be RCU aware
according to the work of Nick).

Marco

[PATCH 00/17] pramfs: persistent and protected RAM filesystem

[Marco Stornelli]

Hi all,

after the merge of pramfs in the LTSI kernel and after the "hot topic" 
NVM Mapping API, here a new submission of pramfs code. Even if the code 
won't be in mainline the review is really useful to me, so any comment 
is welcome.

The patch series is based on 3.5-rc2.

Pramfs documentation:

http://pramfs.sourceforge.net

Git repo:

git://pramfs.git.sourceforge.net/gitroot/pramfs/pramfs

Marco

Re: [PATCH 00/17] pramfs: persistent and protected RAM filesystem

[Christian Stroetmann]

On Sun, June 10, 2012 Marco Stornelli wrote:
> Hi all,
>
> after the merge of pramfs in the LTSI kernel and after the "hot topic" 
> NVM Mapping API, here a new submission of pramfs code. Even if the 
> code won't be in mainline the review is really useful to me, so any 
> comment is welcome.
Hello

I think we have here two cases:
1. "A block of non-volatile RAM separate for normal system memory", 
[documentation Pramfs] and
2. The whole RAM is non-volatile and so the whole situation is changed, 
and an NVM Mapping API is needed and "hotly" discussed.

For 1. your solution is a very good concept that is getting around 
issues solely related with specific optimizations for disc-based file 
systems, like the 2 problems described in the documentation of Pramfs, but
for 2. there is no need for a file system anymore, as we use it today 
while working with a computer system, because data needs not to be 
written to a file system at all, and so the file system will become 
something like a backup system in the most common use cases of a 
computing device, if I should describe it a little bit too provocative. 
In this case your approach taken to handle the 2 problems mentioned in 
the documentation of Pramfs would have to be driven further by focusing 
more on the management of the RAM, the power, and the long-term data 
storage (backup) for harmonizing Pramfs with them. A further point is to 
make Pramfs bootable, if this not already possible somehow.
>
>
> The patch series is based on 3.5-rc2.
>
> Pramfs documentation:
>
> http://pramfs.sourceforge.net
>
> Git repo:
>
> git://pramfs.git.sourceforge.net/gitroot/pramfs/pramfs
>
> Marco

Have fun
Christian Stroetmann

Re: [PATCH 00/17] pramfs: persistent and protected RAM filesystem

[Marco Stornelli]

2012/6/10 Christian Stroetmann <stroetmann@ontolinux.com>:
> On Sun, June 10, 2012 Marco Stornelli wrote:
>>
>> Hi all,
>>
>> after the merge of pramfs in the LTSI kernel and after the "hot topic" NVM
>> Mapping API, here a new submission of pramfs code. Even if the code won't be
>> in mainline the review is really useful to me, so any comment is welcome.
>
> Hello
>
> I think we have here two cases:
> 1. "A block of non-volatile RAM separate for normal system memory",
> [documentation Pramfs] and
> 2. The whole RAM is non-volatile and so the whole situation is changed, and
> an NVM Mapping API is needed and "hotly" discussed.
>
> For 1. your solution is a very good concept that is getting around issues
> solely related with specific optimizations for disc-based file systems, like
> the 2 problems described in the documentation of Pramfs, but
> for 2. there is no need for a file system anymore, as we use it today while
> working with a computer system, because data needs not to be written to a
> file system at all, and so the file system will become something like a
> backup system in the most common use cases of a computing device, if I
> should describe it a little bit too provocative. In this case your approach
> taken to handle the 2 problems mentioned in the documentation of Pramfs
> would have to be driven further by focusing more on the management of the
> RAM, the power, and the long-term data storage (backup) for harmonizing
> Pramfs with them. A further point is to make Pramfs bootable, if this not
> already possible somehow.
>

I have to say that this submission doesn't want to be a complete
answer to the "NVM Mapping API", no way, but eventually only part of
the solution. Pramfs was bootable, but the support was removed,
however the modification would be easy.

Marco

Re: [PATCH 00/17] pramfs: persistent and protected RAM filesystem

[Florian Weimer]

* Marco Stornelli:

> Pramfs documentation:
>
> http://pramfs.sourceforge.net

There doesn't seem to be an fsck.  Is this correct?

Re: [PATCH 00/17] pramfs: persistent and protected RAM filesystem

[Marco Stornelli]

2012/6/13 Florian Weimer <fw@deneb.enyo.de>:
> * Marco Stornelli:
>
>> Pramfs documentation:
>>
>> http://pramfs.sourceforge.net
>
> There doesn't seem to be an fsck.  Is this correct?

It's an ongoing work.

Marco
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/17] pramfs: persistent and protected RAM filesystem

[Marco]

> Hi all,
>
> after the merge of pramfs in the LTSI kernel and after the "hot topic"
> NVM Mapping API, here a new submission of pramfs code. Even if the code
> won't be in mainline the review is really useful to me, so any comment
> is welcome.
>
> The patch series is based on 3.5-rc2.
>
> Pramfs documentation:
>
> http://pramfs.sourceforge.net
>
> Git repo:
>
> git://pramfs.git.sourceforge.net/gitroot/pramfs/pramfs
>
> Marco

No news good news? No comments?

Marco