Hi all,
this is an attempt to include pramfs in mainline. At the moment pramfs
has been included in LTSI kernel. Since last review the code is more
or less the same but, with a really big thanks to Vladimir Davydov and
Parallels, the development of fsck has been started and we have now
the possibility to correct fs errors due to corruption. It's a "young"
tool but we are working on it. You can clone the code from our repos:
git clone git://git.code.sf.net/p/pramfs/code pramfs-code
git clone git://git.code.sf.net/p/pramfs/Tools pramfs-Tools
Marco Stornelli (19):
pramfs: documentation
pramfs: add x86 set_memory_{rw|ro} flag
pramfs: export xip_file_fault
pramfs: add include files
pramfs: super block operations
pramfs: inode operations
pramfs: file operations
pramfs: file operations for dirs
pramfs: inode operations for dirs
pramfs: block allocation
pramfs: ioctl operations
pramfs: symlink operations
pramfs: xip operations
pramfs: extended attributes block description tree
pramfs: extended attributes
pramfs: acl operations
pramfs: write protection
pramfs: test module
pramfs: Kconfig and makefile
Documentation/filesystems/pramfs.txt | 177 ++++++
Documentation/filesystems/xip.txt | 2 +
MAINTAINERS | 9 +
arch/Kconfig | 3 +
arch/x86/Kconfig | 1 +
fs/Kconfig | 6 +-
fs/Makefile | 1 +
fs/pramfs/Kconfig | 72 +++
fs/pramfs/Makefile | 14 +
fs/pramfs/acl.c | 415 +++++++++++++
fs/pramfs/acl.h | 85 +++
fs/pramfs/balloc.c | 160 +++++
fs/pramfs/desctree.c | 181 ++++++
fs/pramfs/desctree.h | 44 ++
fs/pramfs/dir.c | 226 +++++++
fs/pramfs/file.c | 417 +++++++++++++
fs/pramfs/inode.c | 907 +++++++++++++++++++++++++++
fs/pramfs/ioctl.c | 127 ++++
fs/pramfs/namei.c | 391 ++++++++++++
fs/pramfs/pram.h | 283 +++++++++
fs/pramfs/pramfs_test.c | 47 ++
fs/pramfs/super.c | 994 ++++++++++++++++++++++++++++++
fs/pramfs/symlink.c | 76 +++
fs/pramfs/wprotect.c | 39 ++
fs/pramfs/wprotect.h | 144 +++++
fs/pramfs/xattr.c | 1118 ++++++++++++++++++++++++++++++++++
fs/pramfs/xattr.h | 92 +++
fs/pramfs/xattr_security.c | 80 +++
fs/pramfs/xattr_trusted.c | 65 ++
fs/pramfs/xattr_user.c | 69 +++
fs/pramfs/xip.c | 119 ++++
fs/pramfs/xip.h | 33 +
include/linux/fs.h | 2 +
include/linux/pram_fs.h | 48 ++
include/uapi/linux/Kbuild | 1 +
include/uapi/linux/magic.h | 1 +
include/uapi/linux/pram_fs.h | 192 ++++++
mm/filemap_xip.c | 3 +-
38 files changed, 6641 insertions(+), 3 deletions(-)
create mode 100644 Documentation/filesystems/pramfs.txt
create mode 100644 fs/pramfs/Kconfig
create mode 100644 fs/pramfs/Makefile
create mode 100644 fs/pramfs/acl.c
create mode 100644 fs/pramfs/acl.h
create mode 100644 fs/pramfs/balloc.c
create mode 100644 fs/pramfs/desctree.c
create mode 100644 fs/pramfs/desctree.h
create mode 100644 fs/pramfs/dir.c
create mode 100644 fs/pramfs/file.c
create mode 100644 fs/pramfs/inode.c
create mode 100644 fs/pramfs/ioctl.c
create mode 100644 fs/pramfs/namei.c
create mode 100644 fs/pramfs/pram.h
create mode 100644 fs/pramfs/pramfs_test.c
create mode 100644 fs/pramfs/super.c
create mode 100644 fs/pramfs/symlink.c
create mode 100644 fs/pramfs/wprotect.c
create mode 100644 fs/pramfs/wprotect.h
create mode 100644 fs/pramfs/xattr.c
create mode 100644 fs/pramfs/xattr.h
create mode 100644 fs/pramfs/xattr_security.c
create mode 100644 fs/pramfs/xattr_trusted.c
create mode 100644 fs/pramfs/xattr_user.c
create mode 100644 fs/pramfs/xip.c
create mode 100644 fs/pramfs/xip.h
create mode 100644 include/linux/pram_fs.h
create mode 100644 include/uapi/linux/pram_fs.h
--
1.7.3.4
---
On Sat, Sep 7, 2013 at 10:14 AM, Marco Stornelli
<[email protected]> wrote:
> Hi all,
>
> this is an attempt to include pramfs in mainline. At the moment pramfs
> has been included in LTSI kernel. Since last review the code is more
> or less the same but, with a really big thanks to Vladimir Davydov and
> Parallels, the development of fsck has been started and we have now
> the possibility to correct fs errors due to corruption. It's a "young"
> tool but we are working on it. You can clone the code from our repos:
>
> git clone git://git.code.sf.net/p/pramfs/code pramfs-code
> git clone git://git.code.sf.net/p/pramfs/Tools pramfs-Tools
I'm a bit confused, what kind of non-volatile RAM is your fs targeting?
Wouldn't it make sense to use pstore like
arch/powerpc/platforms/pseries/nvram.c does?
> Marco Stornelli (19):
> pramfs: documentation
> pramfs: add x86 set_memory_{rw|ro} flag
> pramfs: export xip_file_fault
> pramfs: add include files
> pramfs: super block operations
> pramfs: inode operations
> pramfs: file operations
> pramfs: file operations for dirs
> pramfs: inode operations for dirs
> pramfs: block allocation
> pramfs: ioctl operations
> pramfs: symlink operations
> pramfs: xip operations
> pramfs: extended attributes block description tree
> pramfs: extended attributes
> pramfs: acl operations
> pramfs: write protection
> pramfs: test module
> pramfs: Kconfig and makefile
>
> Documentation/filesystems/pramfs.txt | 177 ++++++
> Documentation/filesystems/xip.txt | 2 +
> MAINTAINERS | 9 +
> arch/Kconfig | 3 +
> arch/x86/Kconfig | 1 +
> fs/Kconfig | 6 +-
> fs/Makefile | 1 +
> fs/pramfs/Kconfig | 72 +++
> fs/pramfs/Makefile | 14 +
> fs/pramfs/acl.c | 415 +++++++++++++
> fs/pramfs/acl.h | 85 +++
> fs/pramfs/balloc.c | 160 +++++
> fs/pramfs/desctree.c | 181 ++++++
> fs/pramfs/desctree.h | 44 ++
> fs/pramfs/dir.c | 226 +++++++
> fs/pramfs/file.c | 417 +++++++++++++
> fs/pramfs/inode.c | 907 +++++++++++++++++++++++++++
> fs/pramfs/ioctl.c | 127 ++++
> fs/pramfs/namei.c | 391 ++++++++++++
> fs/pramfs/pram.h | 283 +++++++++
> fs/pramfs/pramfs_test.c | 47 ++
> fs/pramfs/super.c | 994 ++++++++++++++++++++++++++++++
> fs/pramfs/symlink.c | 76 +++
> fs/pramfs/wprotect.c | 39 ++
> fs/pramfs/wprotect.h | 144 +++++
> fs/pramfs/xattr.c | 1118 ++++++++++++++++++++++++++++++++++
> fs/pramfs/xattr.h | 92 +++
> fs/pramfs/xattr_security.c | 80 +++
> fs/pramfs/xattr_trusted.c | 65 ++
> fs/pramfs/xattr_user.c | 69 +++
> fs/pramfs/xip.c | 119 ++++
> fs/pramfs/xip.h | 33 +
> include/linux/fs.h | 2 +
> include/linux/pram_fs.h | 48 ++
> include/uapi/linux/Kbuild | 1 +
> include/uapi/linux/magic.h | 1 +
> include/uapi/linux/pram_fs.h | 192 ++++++
> mm/filemap_xip.c | 3 +-
> 38 files changed, 6641 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/filesystems/pramfs.txt
> create mode 100644 fs/pramfs/Kconfig
> create mode 100644 fs/pramfs/Makefile
> create mode 100644 fs/pramfs/acl.c
> create mode 100644 fs/pramfs/acl.h
> create mode 100644 fs/pramfs/balloc.c
> create mode 100644 fs/pramfs/desctree.c
> create mode 100644 fs/pramfs/desctree.h
> create mode 100644 fs/pramfs/dir.c
> create mode 100644 fs/pramfs/file.c
> create mode 100644 fs/pramfs/inode.c
> create mode 100644 fs/pramfs/ioctl.c
> create mode 100644 fs/pramfs/namei.c
> create mode 100644 fs/pramfs/pram.h
> create mode 100644 fs/pramfs/pramfs_test.c
> create mode 100644 fs/pramfs/super.c
> create mode 100644 fs/pramfs/symlink.c
> create mode 100644 fs/pramfs/wprotect.c
> create mode 100644 fs/pramfs/wprotect.h
> create mode 100644 fs/pramfs/xattr.c
> create mode 100644 fs/pramfs/xattr.h
> create mode 100644 fs/pramfs/xattr_security.c
> create mode 100644 fs/pramfs/xattr_trusted.c
> create mode 100644 fs/pramfs/xattr_user.c
> create mode 100644 fs/pramfs/xip.c
> create mode 100644 fs/pramfs/xip.h
> create mode 100644 include/linux/pram_fs.h
> create mode 100644 include/uapi/linux/pram_fs.h
>
> --
> 1.7.3.4
> ---
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Thanks,
//richard
Il 07/09/2013 16:58, richard -rw- weinberger ha scritto:
> On Sat, Sep 7, 2013 at 10:14 AM, Marco Stornelli
> <[email protected]> wrote:
>> Hi all,
>>
>> this is an attempt to include pramfs in mainline. At the moment pramfs
>> has been included in LTSI kernel. Since last review the code is more
>> or less the same but, with a really big thanks to Vladimir Davydov and
>> Parallels, the development of fsck has been started and we have now
>> the possibility to correct fs errors due to corruption. It's a "young"
>> tool but we are working on it. You can clone the code from our repos:
>>
>> git clone git://git.code.sf.net/p/pramfs/code pramfs-code
>> git clone git://git.code.sf.net/p/pramfs/Tools pramfs-Tools
>
> I'm a bit confused, what kind of non-volatile RAM is your fs targeting?
> Wouldn't it make sense to use pstore like
> arch/powerpc/platforms/pseries/nvram.c does?
>
Usually battery-backed SRAM, but actually it can be used in any piece of
ram directly accessible and it provides a normal and complete fs
interface. Usually I do the fs test remapping my system ram. You can
find documentation here:
http://pramfs.sourceforge.net
Marco
Il 07/09/2013 10:14, Marco Stornelli ha scritto:
> Hi all,
>
> this is an attempt to include pramfs in mainline. At the moment pramfs
> has been included in LTSI kernel. Since last review the code is more
> or less the same but, with a really big thanks to Vladimir Davydov and
> Parallels, the development of fsck has been started and we have now
> the possibility to correct fs errors due to corruption. It's a "young"
> tool but we are working on it. You can clone the code from our repos:
>
> git clone git://git.code.sf.net/p/pramfs/code pramfs-code
> git clone git://git.code.sf.net/p/pramfs/Tools pramfs-Tools
>
Other comments before v2? Please let me know.
Marco
On 09/07/2013 08:22 PM, Marco Stornelli wrote:
> Il 07/09/2013 16:58, richard -rw- weinberger ha scritto:
>> On Sat, Sep 7, 2013 at 10:14 AM, Marco Stornelli
>> <[email protected]> wrote:
>>> Hi all,
>>>
>>> this is an attempt to include pramfs in mainline. At the moment pramfs
>>> has been included in LTSI kernel. Since last review the code is more
>>> or less the same but, with a really big thanks to Vladimir Davydov and
>>> Parallels, the development of fsck has been started and we have now
>>> the possibility to correct fs errors due to corruption. It's a "young"
>>> tool but we are working on it. You can clone the code from our repos:
>>>
>>> git clone git://git.code.sf.net/p/pramfs/code pramfs-code
>>> git clone git://git.code.sf.net/p/pramfs/Tools pramfs-Tools
>>
>> I'm a bit confused, what kind of non-volatile RAM is your fs targeting?
>> Wouldn't it make sense to use pstore like
>> arch/powerpc/platforms/pseries/nvram.c does?
>>
>
> Usually battery-backed SRAM, but actually it can be used in any piece
> of ram directly accessible and it provides a normal and complete fs
> interface. Usually I do the fs test remapping my system ram. You can
> find documentation here:
>
> http://pramfs.sourceforge.net
I'd like to add that in contrast to pstore, pramfs allows storing any
files in it, not only system logs. This can be of value even on machines
w/o special devices like sram/nvram: one can store data that should be
quickly restored after reboot in conventional ram and use kexec to boot
to a new kernel. One of the use cases of this could be checkpointing
time-critical services to ram (using criu.org) to be quickly restored
after a kernel update providing almost zero-downtime.
>
> Marco
Il 08/09/2013 11:05, Vladimir Davydov ha scritto:
> On 09/07/2013 08:22 PM, Marco Stornelli wrote:
>> Il 07/09/2013 16:58, richard -rw- weinberger ha scritto:
>>> On Sat, Sep 7, 2013 at 10:14 AM, Marco Stornelli
>>> <[email protected]> wrote:
>>>> Hi all,
>>>>
>>>> this is an attempt to include pramfs in mainline. At the moment pramfs
>>>> has been included in LTSI kernel. Since last review the code is more
>>>> or less the same but, with a really big thanks to Vladimir Davydov and
>>>> Parallels, the development of fsck has been started and we have now
>>>> the possibility to correct fs errors due to corruption. It's a "young"
>>>> tool but we are working on it. You can clone the code from our repos:
>>>>
>>>> git clone git://git.code.sf.net/p/pramfs/code pramfs-code
>>>> git clone git://git.code.sf.net/p/pramfs/Tools pramfs-Tools
>>>
>>> I'm a bit confused, what kind of non-volatile RAM is your fs targeting?
>>> Wouldn't it make sense to use pstore like
>>> arch/powerpc/platforms/pseries/nvram.c does?
>>>
>>
>> Usually battery-backed SRAM, but actually it can be used in any piece
>> of ram directly accessible and it provides a normal and complete fs
>> interface. Usually I do the fs test remapping my system ram. You can
>> find documentation here:
>>
>> http://pramfs.sourceforge.net
>
> I'd like to add that in contrast to pstore, pramfs allows storing any
> files in it, not only system logs. This can be of value even on machines
> w/o special devices like sram/nvram: one can store data that should be
> quickly restored after reboot in conventional ram and use kexec to boot
> to a new kernel. One of the use cases of this could be checkpointing
> time-critical services to ram (using criu.org) to be quickly restored
> after a kernel update providing almost zero-downtime.
>
Yep. I add that if you use your system ram, your bootloader must be
aware because it mustn't clear your memory after a reboot, indeed you
can find reference of Pramfs in Uboot documentation:
http://www.denx.de/wiki/view/DULG/PersistentRAMFileSystem
Marco
On Sat, Sep 07, 2013 at 10:14:04AM +0200, Marco Stornelli wrote:
> Hi all,
>
> this is an attempt to include pramfs in mainline. At the moment pramfs
> has been included in LTSI kernel. Since last review the code is more
> or less the same but, with a really big thanks to Vladimir Davydov and
> Parallels, the development of fsck has been started and we have now
> the possibility to correct fs errors due to corruption. It's a "young"
> tool but we are working on it. You can clone the code from our repos:
>
> git clone git://git.code.sf.net/p/pramfs/code pramfs-code
> git clone git://git.code.sf.net/p/pramfs/Tools pramfs-Tools
The 1980s are calling, and they want their filesytem back. :)
So, Devil's Advocate time. Convince me as to why pramfs should be
merged.
Why do we want a single threaded, block based filesystem (i.e. based
on 1980s filesystem technology) as the basis for storing information
in persistent memory in 2013? Persistent memory over the next few
years is going to require support for 10s to 100s of TB of storage
and concurrency of 100s to 1000s of CPU cores banging on the memory
at full speed. By design, pramfs is simply not sufficient for our
future needs.
pramfs uses indirect block indexing - not even extents - for file
data. That doesn't scale effectively to large files or fragmented
files, which is what the single threaded bitmap block allocator will
cause because it's a just a basic "find the next zero bit in the
bitmap" allocator.
It doesn't have any recovery mechanisms built in to it (like a redo
log) nor can it do atomic multi-variable updates to persistent
memory segments, so a crash at the wrong time will leave you with a
corrupted filesystem. We learnt this lesson years ago - fsck on
every boot does not scale and people hate having boot interrupted by
needing to manually intervene in recovery operations to get their
system back up and running.
The directory structure is a linked list of inodes, linked by inode
number. The operations to add or remove an inode are not atomic from
a persistent memory perspsective and so a crash between them will
result in a corrupt directory. Lookup has to iterate the linked list
to find a name match - that's not going to scale at all, and it's
completely serialised, too, so concurrent lookups into the same
directory are out of the question.
Further, the readdir cookie is the position of the inode in the
linked list, which means telldir/seekdir are fundamentally broken in
the presence of directory modification. It also uses the magic
number of "3" to indicate the end of the directory, which is kinda
weird.
If we were in the 1980s, then pramfs would be wonderful. The reality
is, though, it is 2013 and we have another 30-odd years of
filesystem development knowledge under our belts. IMO, pramfs won't
even effectively scale to the needs of a modern smart phone, let
alone a server with a couple of terabytes of persistent memory.
>From that perspective, pramfs is really just a toy and not something
we could use as the basis of future persistent memory storage
development because we'd need to start again from scratch.
IOWs, I'm looking at pramfs with an eye to 5-10 years in the future.
I can see lots of problems just with 5 year old technology in pramfs
and AFAIC just because it's been included in a LSTI kernel doesn't
mean we should include it mainline. I'm not denying that We need a
persistent memory filesystem in mainline, but we don't want to merge
something that already borders on obsolesence and then have to both
maintain it and simultaneously design a new filesystem that handles
our current and future needs...
Cheers,
Dave.
--
Dave Chinner
[email protected]
Il 09/09/2013 01:40, Dave Chinner ha scritto:
> On Sat, Sep 07, 2013 at 10:14:04AM +0200, Marco Stornelli wrote:
>> Hi all,
>>
>> this is an attempt to include pramfs in mainline. At the moment pramfs
>> has been included in LTSI kernel. Since last review the code is more
>> or less the same but, with a really big thanks to Vladimir Davydov and
>> Parallels, the development of fsck has been started and we have now
>> the possibility to correct fs errors due to corruption. It's a "young"
>> tool but we are working on it. You can clone the code from our repos:
>>
>> git clone git://git.code.sf.net/p/pramfs/code pramfs-code
>> git clone git://git.code.sf.net/p/pramfs/Tools pramfs-Tools
>
> The 1980s are calling, and they want their filesytem back. :)
>
> So, Devil's Advocate time. Convince me as to why pramfs should be
> merged.
>
Never used in my embedded project with more of few mb, and maybe you are
asking for cases not targeted. Pramfs is in LTSI not why I asked Greg to
include it, but because there are several companies asked me to do. The
message wasn't "hey, pramfs is in LTSI, so we must include it in
mainline" but it was only a consideration and indication that there is
need of something like that out there. Sure we can talk about if it's
the best option or not, however this is the real world. In addition,
this comment is exactly why the kernel community is not really friendly
to be time-to-market, we have to say it. It's not possible to have a 10
years review. It's a never ending story. Maybe when there is a big
company behind a patch the behavior is different and I can do several
examples, but I don't want to say more, life is hard, I know, even in
the kernel community. I think I can close the review here, my delusion
is not for me, I can live well in each case, but for the companies and
all the people believes in the project.
Thanks to all.
Marco
On Mon, Sep 09, 2013 at 08:13:51PM +0200, Marco Stornelli wrote:
> Il 09/09/2013 01:40, Dave Chinner ha scritto:
> >On Sat, Sep 07, 2013 at 10:14:04AM +0200, Marco Stornelli wrote:
> >>Hi all,
> >>
> >>this is an attempt to include pramfs in mainline. At the moment pramfs
> >>has been included in LTSI kernel. Since last review the code is more
> >>or less the same but, with a really big thanks to Vladimir Davydov and
> >>Parallels, the development of fsck has been started and we have now
> >>the possibility to correct fs errors due to corruption. It's a "young"
> >>tool but we are working on it. You can clone the code from our repos:
> >>
> >>git clone git://git.code.sf.net/p/pramfs/code pramfs-code
> >>git clone git://git.code.sf.net/p/pramfs/Tools pramfs-Tools
> >
> >The 1980s are calling, and they want their filesytem back. :)
> >
> >So, Devil's Advocate time. Convince me as to why pramfs should be
> >merged.
> >
>
> Never used in my embedded project with more of few mb, and maybe you
> are asking for cases not targeted. Pramfs is in LTSI not why I asked
> Greg to include it, but because there are several companies asked me
> to do. The message wasn't "hey, pramfs is in LTSI, so we must
> include it in mainline" but it was only a consideration and
> indication that there is need of something like that out there. Sure
> we can talk about if it's the best option or not, however this is
> the real world.
Then lets talk about whether it's the best solution or not. You've
said "too hard, I'm going home" the moment someone has asked hard
questions and pointed out problems. You haven't even attempted to
discuss the issues or explain why things were done in the way they
have been done. Instead, you've just cut all the context out
completely and handwaved about time to market issues and upstream
being unfriendly.
News Flash: I'm not here to be your friend.
I'm here to make sure code that is merged is robust and solid and
solves the problems we know need to be solved. I know that we need a
solution to persistent memory storage, but pramfs has many
deficiencies and doesn't address the requirements that vendors of
emerging technologies have communicated to us in various public
forums.
You may not know about these requirements - that's part of the
iterative peer review process - you learn about other people's
requirements for the technology and try to address them or explain
why you're not going to handle those cases...
> It's not possible to have a 10 years review. It's a never
> ending story.
Filesystems architectures last much longer than 10 years. Suitablity
of the current filesystem architecture for known medium- and
long-term needs is definitely part of any code review. There's lots
of people on -fsdevel that have the knowledge and experience to be
able to do this sort of review....
Cheers,
Dave.
--
Dave Chinner
[email protected]