pramfs

PATCH In review Marco Stornelli 4 participants 9 messages Sep 7, 2013 – Sep 9, 2013 VFS

lore

Share & tools

lore

Marco Stornelli

author

2013-09-07 08:21 UTC #0 lore raw

cover pramfs

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

Signature · 2 lines

1.7.3.4
---

richard -rw- weinberger

2013-09-07 14:58 UTC #1 lore raw

Quoted 11 lines · Marco Stornelli

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?

Quoted 97 lines

 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

Signature · 2 lines

Thanks,
//richard

Marco Stornelli

author

2013-09-07 16:22 UTC #2 lore raw

Il 07/09/2013 16:58, richard -rw- weinberger ha scritto:

Quoted 11 lines

Quoted 9 lines · Marco Stornelli
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:

Quoted 7 lines

Quoted 2 lines
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

Marco Stornelli

author

2013-09-08 06:49 UTC #5 lore raw

In reply to Marco Stornelli

Il 07/09/2013 10:14, Marco Stornelli ha scritto:

Quoted 9 lines

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:

Quoted 3 lines

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

Vladimir Davydov

2013-09-08 09:05 UTC #3 lore raw

In reply to Marco Stornelli

Quoted 15 lines · Marco Stornelli

Il 07/09/2013 16:58, richard -rw- weinberger ha scritto:
Quoted 14 lines
Quoted 11 lines · Marco Stornelli
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

Quoted 8 lines

Quoted 4 lines
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.

Quoted 2 lines

Marco

Marco Stornelli

author

2013-09-08 09:41 UTC #4 lore raw

Il 08/09/2013 11:05, Vladimir Davydov ha scritto:

Quoted 28 lines · Marco Stornelli

Quoted 20 lines
Il 07/09/2013 16:58, richard -rw- weinberger ha scritto:
Quoted 11 lines
Quoted 9 lines · Marco Stornelli
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:
Quoted 7 lines
Quoted 2 lines
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?
Quoted 6 lines
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

Quoted 8 lines

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

Dave Chinner

2013-09-08 23:40 UTC #6 lore raw

In reply to Marco Stornelli

Quoted 11 lines · Marco Stornelli

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.

Quoted 1 line

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.

Signature · 2 lines

Dave Chinner
[email protected]

Marco Stornelli

author

2013-09-09 18:13 UTC #7 lore raw

Il 09/09/2013 01:40, Dave Chinner ha scritto:

Quoted 10 lines · Marco Stornelli

Quoted 9 lines
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:

Quoted 8 lines

Quoted 2 lines
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

Dave Chinner

2013-09-09 23:28 UTC #8 lore raw

Quoted 20 lines · Marco Stornelli

Il 09/09/2013 01:40, Dave Chinner ha scritto:
Quoted 10 lines · Marco Stornelli
Quoted 9 lines
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:
Quoted 8 lines
Quoted 2 lines
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.

Quoted 8 lines

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

Quoted 2 lines

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.

Signature · 2 lines

Dave Chinner
[email protected]