pramfs-devel — Development discussions

Re: [Pramfs-devel] [PATCH pramfs] Move inode flag definitions to uapi header

[Marco S. <mar...@gm...>]

Il 29/08/2013 17:59, Vladimir Davydov ha scritto:
> Inode flags are used by the userspace tool fsck.pramfs.
>
> Signed-off-by: Vladimir Davydov <vda...@pa...>
> ---

Applied.

Marco

Re: [Pramfs-devel] [PATCH pramfs] Move xattr definitions to uapi header

[Marco S. <mar...@gm...>]

Il 29/08/2013 18:00, Vladimir Davydov ha scritto:
> This is required by the userspace tool fsck.pramfs to check inode xattr
> blocks.
>
> Signed-off-by: Vladimir Davydov <vda...@pa...>
> ---

Applied.

Marco

[Pramfs-devel] [PATCH pramfs] Move xattr definitions to uapi header

[Vladimir D. <vda...@pa...>]

This is required by the userspace tool fsck.pramfs to check inode xattr
blocks.

Signed-off-by: Vladimir Davydov <vda...@pa...>
---
 pram_fs_uapi.h |   46 ++++++++++++++++++++++++++++++++++++++++++++++
 xattr.h        |   42 ------------------------------------------
 2 files changed, 46 insertions(+), 42 deletions(-)

diff --git a/pram_fs_uapi.h b/pram_fs_uapi.h
index 0ac3172..b488674 100644
--- a/pram_fs_uapi.h
+++ b/pram_fs_uapi.h
@@ -143,4 +143,50 @@ struct pram_super_block {
 /* The root inode follows immediately after the redundant super block */
 #define PRAM_ROOT_INO (PRAM_SB_SIZE*2)
 
+/*
+ * XATTR related
+ */
+
+/* Magic value in attribute blocks */
+#define PRAM_XATTR_MAGIC		0x6d617270
+
+/* Maximum number of references to one attribute block */
+#define PRAM_XATTR_REFCOUNT_MAX		1024
+
+/* Name indexes */
+#define PRAM_XATTR_INDEX_USER			1
+#define PRAM_XATTR_INDEX_POSIX_ACL_ACCESS	2
+#define PRAM_XATTR_INDEX_POSIX_ACL_DEFAULT	3
+#define PRAM_XATTR_INDEX_TRUSTED		4
+#define PRAM_XATTR_INDEX_SECURITY	        5
+
+struct pram_xattr_header {
+	__be32	h_magic;	/* magic number for identification */
+	__be32	h_refcount;	/* reference count */
+	__be32	h_hash;		/* hash value of all attributes */
+	__u32	h_reserved[4];	/* zero right now */
+};
+
+struct pram_xattr_entry {
+	__u8	e_name_len;	/* length of name */
+	__u8	e_name_index;	/* attribute name index */
+	__be16	e_value_offs;	/* offset in disk block of value */
+	__be32	e_value_block;	/* disk block attribute is stored on (n/i) */
+	__be32	e_value_size;	/* size of attribute value */
+	__be32	e_hash;		/* hash value of name and value */
+	char	e_name[0];	/* attribute name */
+};
+
+#define PRAM_XATTR_PAD_BITS		2
+#define PRAM_XATTR_PAD		(1<<PRAM_XATTR_PAD_BITS)
+#define PRAM_XATTR_ROUND		(PRAM_XATTR_PAD-1)
+#define PRAM_XATTR_LEN(name_len) \
+	(((name_len) + PRAM_XATTR_ROUND + \
+	sizeof(struct pram_xattr_entry)) & ~PRAM_XATTR_ROUND)
+#define PRAM_XATTR_NEXT(entry) \
+	((struct pram_xattr_entry *)( \
+	  (char *)(entry) + PRAM_XATTR_LEN((entry)->e_name_len)))
+#define PRAM_XATTR_SIZE(size) \
+	(((size) + PRAM_XATTR_ROUND) & ~PRAM_XATTR_ROUND)
+
 #endif	/* _UAPI_LINUX_PRAM_FS_H */
diff --git a/xattr.h b/xattr.h
index 617273b..65c7e6d 100644
--- a/xattr.h
+++ b/xattr.h
@@ -17,48 +17,6 @@
 #include <linux/init.h>
 #include <linux/xattr.h>
 
-/* Magic value in attribute blocks */
-#define PRAM_XATTR_MAGIC		0x6d617270
-
-/* Maximum number of references to one attribute block */
-#define PRAM_XATTR_REFCOUNT_MAX		1024
-
-/* Name indexes */
-#define PRAM_XATTR_INDEX_USER			1
-#define PRAM_XATTR_INDEX_POSIX_ACL_ACCESS	2
-#define PRAM_XATTR_INDEX_POSIX_ACL_DEFAULT	3
-#define PRAM_XATTR_INDEX_TRUSTED		4
-#define PRAM_XATTR_INDEX_SECURITY	        5
-
-struct pram_xattr_header {
-	__be32	h_magic;	/* magic number for identification */
-	__be32	h_refcount;	/* reference count */
-	__be32	h_hash;		/* hash value of all attributes */
-	__u32	h_reserved[4];	/* zero right now */
-};
-
-struct pram_xattr_entry {
-	__u8	e_name_len;	/* length of name */
-	__u8	e_name_index;	/* attribute name index */
-	__be16	e_value_offs;	/* offset in disk block of value */
-	__be32	e_value_block;	/* disk block attribute is stored on (n/i) */
-	__be32	e_value_size;	/* size of attribute value */
-	__be32	e_hash;		/* hash value of name and value */
-	char	e_name[0];	/* attribute name */
-};
-
-#define PRAM_XATTR_PAD_BITS		2
-#define PRAM_XATTR_PAD		(1<<PRAM_XATTR_PAD_BITS)
-#define PRAM_XATTR_ROUND		(PRAM_XATTR_PAD-1)
-#define PRAM_XATTR_LEN(name_len) \
-	(((name_len) + PRAM_XATTR_ROUND + \
-	sizeof(struct pram_xattr_entry)) & ~PRAM_XATTR_ROUND)
-#define PRAM_XATTR_NEXT(entry) \
-	((struct pram_xattr_entry *)( \
-	  (char *)(entry) + PRAM_XATTR_LEN((entry)->e_name_len)))
-#define PRAM_XATTR_SIZE(size) \
-	(((size) + PRAM_XATTR_ROUND) & ~PRAM_XATTR_ROUND)
-
 #ifdef CONFIG_PRAMFS_XATTR
 
 extern const struct xattr_handler pram_xattr_user_handler;
-- 
1.7.10.4

[Pramfs-devel] [PATCH pramfs] Move inode flag definitions to uapi header

[Vladimir D. <vda...@pa...>]

Inode flags are used by the userspace tool fsck.pramfs.

Signed-off-by: Vladimir Davydov <vda...@pa...>
---
 pram.h         |   17 -----------------
 pram_fs_uapi.h |   18 ++++++++++++++++++
 2 files changed, 18 insertions(+), 17 deletions(-)

diff --git a/pram.h b/pram.h
index d7ae16a..08d724b 100644
--- a/pram.h
+++ b/pram.h
@@ -52,23 +52,6 @@ do {                                                                   \
 #define set_opt(o, opt)		(o |= PRAM_MOUNT_##opt)
 #define test_opt(sb, opt)	(PRAM_SB(sb)->s_mount_opt & PRAM_MOUNT_##opt)
 
-/*
- * Pram inode flags
- *
- * PRAM_EOFBLOCKS_FL	There are blocks allocated beyond eof
- */
-#define PRAM_EOFBLOCKS_FL	0x20000000
-/* Flags that should be inherited by new inodes from their parent. */
-#define PRAM_FL_INHERITED (FS_SECRM_FL | FS_UNRM_FL | FS_COMPR_FL |\
-			   FS_SYNC_FL | FS_NODUMP_FL | FS_NOATIME_FL | \
-			   FS_COMPRBLK_FL | FS_NOCOMP_FL | FS_JOURNAL_DATA_FL |\
-			   FS_NOTAIL_FL | FS_DIRSYNC_FL)
-/* Flags that are appropriate for regular files (all but dir-specific ones). */
-#define PRAM_REG_FLMASK (~(FS_DIRSYNC_FL | FS_TOPDIR_FL))
-/* Flags that are appropriate for non-directories/regular files. */
-#define PRAM_OTHER_FLMASK (FS_NODUMP_FL | FS_NOATIME_FL)
-#define PRAM_FL_USER_VISIBLE (FS_FL_USER_VISIBLE | PRAM_EOFBLOCKS_FL)
-
 /* Function Prototypes */
 extern void pram_error_mng(struct super_block *sb, const char *fmt, ...);
 
diff --git a/pram_fs_uapi.h b/pram_fs_uapi.h
index ef0507b..0ac3172 100644
--- a/pram_fs_uapi.h
+++ b/pram_fs_uapi.h
@@ -16,6 +16,7 @@
 
 #include <linux/types.h>
 #include <linux/magic.h>
+#include <linux/fs.h>
 
 /*
  * The PRAM filesystem constants/structures
@@ -33,6 +34,23 @@
 #define PRAM_MOUNT_ERRORS_PANIC		0x000040  /* Panic on errors */
 
 /*
+ * Pram inode flags
+ *
+ * PRAM_EOFBLOCKS_FL	There are blocks allocated beyond eof
+ */
+#define PRAM_EOFBLOCKS_FL	0x20000000
+/* Flags that should be inherited by new inodes from their parent. */
+#define PRAM_FL_INHERITED (FS_SECRM_FL | FS_UNRM_FL | FS_COMPR_FL |\
+			   FS_SYNC_FL | FS_NODUMP_FL | FS_NOATIME_FL | \
+			   FS_COMPRBLK_FL | FS_NOCOMP_FL | FS_JOURNAL_DATA_FL |\
+			   FS_NOTAIL_FL | FS_DIRSYNC_FL)
+/* Flags that are appropriate for regular files (all but dir-specific ones). */
+#define PRAM_REG_FLMASK (~(FS_DIRSYNC_FL | FS_TOPDIR_FL))
+/* Flags that are appropriate for non-directories/regular files. */
+#define PRAM_OTHER_FLMASK (FS_NODUMP_FL | FS_NOATIME_FL)
+#define PRAM_FL_USER_VISIBLE (FS_FL_USER_VISIBLE | PRAM_EOFBLOCKS_FL)
+
+/*
  * Maximal count of links to a file
  */
 #define PRAM_LINK_MAX		32000
-- 
1.7.10.4

Re: [Pramfs-devel] R: Re: pramfstools

[Vladimir D. <vda...@pa...>]

So I committed the inital 0.0.1 version of pramfstools.

Changes from the previous version:

  * changed crc16 to crc32
  * removed pram_fs.h, now it is included directly from linux headers
  * updated README with updated linux headers prerequisite for build

So now if you want to build the tools, you will need updated linux 
headers installed (can be installed with `make headers_install' typed 
from the Linux source tree). If they are installed to a non-standard 
location, path to them can be specified as follows:

  $ make CFLAGS=-I<path-to-linux-headers>

Thanks.

On 08/27/2013 06:49 PM, marco wrote:
> I added you to the project. You should now be able to push into the 
> git repo. Let me know if you've got problems.
>
> Marco
>
>
>
> -------- Messaggio originale --------
> Da: Vladimir Davydov <vda...@pa...>
> Data: 27/08/2013 09:37 (GMT+01:00)
> A: Marco Stornelli <mar...@gm...>
> Cc: pra...@li...
> Oggetto: Re: pramfstools
>
>
> On 08/26/2013 07:08 PM, Marco Stornelli wrote:
> > Hi,
> >
> > Il 25/08/2013 20:28, Vladimir Davydov ha scritto:
> >> Hello,
> >>
> >> I've written the fsck utility for PRAM FS. You can clone it from
> >> git://github.com/locker/pramfstools
> >>
> >> Note that it requires read (write in case of repair) access to 
> /dev/mem,
> >> because AFAIK this is currently the only way to operate with PRAM FS
> >> image, so STRICT_DEVMEM kernel config option must be turned off.
> >>
> >> Also note that currently it does not support PRAM FS xattrs, but I'm
> >> planning to work this out.
> >>
> >> For more information and example of use cases, see README.
> >>
> >> I would appreciate if you could look at this. Perhaps it'll be worth
> >> merging this to the PRAM FS repo at sourceforge if you find the code
> >> acceptable, because IMHO it would be nice to have all the bits 
> regarding
> >> PRAM FS gathered in one place. Anyway, if you have any comments
> >> regarding the tool's interface/coding style/etc, please let me know.
> >>
> >> Thanks.
> >
> > Great. A really good work. I create a new git repo:
> >
> > git clone git://git.code.sf.net/p/pramfs/Tools pramfs-Tools
> >
> > If you have got a sourceforge account I can add you to the project and
> > I can give you write access.
>
> I've just joined :-) username is vdavydov825
>
> > I didn't read the code in a deep way but my first comments:
> >
> > 1) I think it's a good idea to check at the beginning if the fs is
> > already mounted. On line check and repair can be dangerous. We can
> > read the proc files to know it;
>
> Agree.
>
> >
> > 2) The pram_fs.h shouldn't be tracked in the repo. When you compile
> > you should have a reference in your kernel tree. Indeed this file
> > isn't in the private fs folder just for that;
>
> Agree.
>
> >
> > 3) With the next version we have to change a couple of things: crc is
> > now 32 bit because it has got better performance and now the
> > structures are big enough to require a 32 bit crc.In addition I think
> > we have to manage the O_TMPFILE, we could have inode without any links
> > (but maybe this case is already covered in "orphaned inodes", I didn't
> > see it yet).
>
> I guess check_orphaned_inodes() should handle O_TMPFILE properly
> although initially I implemented it for another reason. This is how FS
> tree check currently works:
>
> 1. Walk over FS tree starting from the root and descending to leafs
> marking all found inodes as 'reachable'
>
> 2. Iterate over the inode table checking if there are active (i.e. not
> deleted) inodes that are not marked as 'reachable' - I call them
> orphaned inodes. For each orphaned inode, first try to find its parent
> as specified by i_d.d_parent. If found, try to repair it, i.e. link back
> to the parent dir. If there is no active parent or parent link is
> invalid, prompt to delete it, because it's unrecoverable.
>
> Initially, check for orphaned inodes was implemented, because PRAM FS
> directory entry structure is rather unreliable - corruption of an inode
> will result in loss of all inodes that follow it in the same directory.
> To avoid this, I try to recover inodes that were not found reachable.
>
> However, this should also work for O_TMPFILE. AFAIU, O_TMPFILE is in
> fact the same as an open unlinked file, i.e. it has i_links_count=0 and
> i_d zeroed out, but i_dtime is not set and i_mode is not cleared yet so
> that it does not appear as deleted. So it won't be found and marked as
> 'reachable' during walk over FS tree. Thus it will be later found as
> orphaned and unrecoverable since i_d.d_parent=0, and prompted to be
> deleted. The deletion won't free blocks allocated by the inode
> immediately, but the blocks should be freed in check_block_alloc()
> automatically, because they will also become orphaned with the deletion
> of the inode.
>
> I will fix the code according to your comments above and notify you when
> it's done.
>
> Thanks.

Re: [Pramfs-devel] pramfstools

[Marco S. <mar...@gm...>]

Il 27/08/2013 09:37, Vladimir Davydov ha scritto:
> On 08/26/2013 07:08 PM, Marco Stornelli wrote:
>> Hi,
>>
>> Il 25/08/2013 20:28, Vladimir Davydov ha scritto:
>>> Hello,
>>>
>>> I've written the fsck utility for PRAM FS. You can clone it from
>>> git://github.com/locker/pramfstools
>>>
>>> Note that it requires read (write in case of repair) access to /dev/mem,
>>> because AFAIK this is currently the only way to operate with PRAM FS
>>> image, so STRICT_DEVMEM kernel config option must be turned off.
>>>
>>> Also note that currently it does not support PRAM FS xattrs, but I'm
>>> planning to work this out.
>>>
>>> For more information and example of use cases, see README.
>>>
>>> I would appreciate if you could look at this. Perhaps it'll be worth
>>> merging this to the PRAM FS repo at sourceforge if you find the code
>>> acceptable, because IMHO it would be nice to have all the bits regarding
>>> PRAM FS gathered in one place. Anyway, if you have any comments
>>> regarding the tool's interface/coding style/etc, please let me know.
>>>
>>> Thanks.
>>
>> Great. A really good work. I create a new git repo:
>>
>> git clone git://git.code.sf.net/p/pramfs/Tools pramfs-Tools
>>
>> If you have got a sourceforge account I can add you to the project and
>> I can give you write access.
>
> I've just joined :-) username is vdavydov825
>
>> I didn't read the code in a deep way but my first comments:
>>
>> 1) I think it's a good idea to check at the beginning if the fs is
>> already mounted. On line check and repair can be dangerous. We can
>> read the proc files to know it;
>
> Agree.
>
>>
>> 2) The pram_fs.h shouldn't be tracked in the repo. When you compile
>> you should have a reference in your kernel tree. Indeed this file
>> isn't in the private fs folder just for that;
>
> Agree.
>
>>
>> 3) With the next version we have to change a couple of things: crc is
>> now 32 bit because it has got better performance and now the
>> structures are big enough to require a 32 bit crc.In addition I think
>> we have to manage the O_TMPFILE, we could have inode without any links
>> (but maybe this case is already covered in "orphaned inodes", I didn't
>> see it yet).
>
> I guess check_orphaned_inodes() should handle O_TMPFILE properly
> although initially I implemented it for another reason. This is how FS
> tree check currently works:
>
> 1. Walk over FS tree starting from the root and descending to leafs
> marking all found inodes as 'reachable'
>
> 2. Iterate over the inode table checking if there are active (i.e. not
> deleted) inodes that are not marked as 'reachable' - I call them
> orphaned inodes. For each orphaned inode, first try to find its parent
> as specified by i_d.d_parent. If found, try to repair it, i.e. link back
> to the parent dir. If there is no active parent or parent link is
> invalid, prompt to delete it, because it's unrecoverable.

Ok. Here actually we can follow another way, but it can be an item on 
our todo list. Instead to delete it, we can create a lost+found folder 
and attach them to this new folder.

>
> Initially, check for orphaned inodes was implemented, because PRAM FS
> directory entry structure is rather unreliable - corruption of an inode
> will result in loss of all inodes that follow it in the same directory.
> To avoid this, I try to recover inodes that were not found reachable.
>
> However, this should also work for O_TMPFILE. AFAIU, O_TMPFILE is in
> fact the same as an open unlinked file, i.e. it has i_links_count=0 and
> i_d zeroed out, but i_dtime is not set and i_mode is not cleared yet so
> that it does not appear as deleted. So it won't be found and marked as
> 'reachable' during walk over FS tree. Thus it will be later found as
> orphaned and unrecoverable since i_d.d_parent=0, and prompted to be
> deleted. The deletion won't free blocks allocated by the inode
> immediately, but the blocks should be freed in check_block_alloc()
> automatically, because they will also become orphaned with the deletion
> of the inode.
>

Yep, I quite agree.

> I will fix the code according to your comments above and notify you when
> it's done.
>
> Thanks.

Thanks again.

Marco

Re: [Pramfs-devel] [PATCH pramfs] Introduce uapi header

[Vladimir D. <vda...@pa...>]

On 08/27/2013 07:11 PM, Marco Stornelli wrote:
> Il 27/08/2013 11:40, Vladimir Davydov ha scritto:
>> This patch transforms pram_fs.h to be a uapi header, because it is
>> required by PRAM FS userspace tools.
>>
>> Signed-off-by: Vladimir Davydov<vda...@pa...>
>
> Ack for both. Would you mind sending the patch inline instead of 
> attachment the next time (maybe with git send-email)? It's easier to 
> import it with git. Thanks.

Actually I already use git-send-email with --attach option :-), so 
git-am should have applied them. Anyway next time I'll send patches inline.

Thanks.

Re: [Pramfs-devel] [PATCH pramfs] Introduce uapi header

[Marco S. <mar...@gm...>]

Il 27/08/2013 11:40, Vladimir Davydov ha scritto:
> This patch transforms pram_fs.h to be a uapi header, because it is
> required by PRAM FS userspace tools.
>
> Signed-off-by: Vladimir Davydov<vda...@pa...>

Ack for both. Would you mind sending the patch inline instead of 
attachment the next time (maybe with git send-email)? It's easier to 
import it with git. Thanks.

Marco

[Pramfs-devel] R: Re: pramfstools

[marco <mar...@gm...>]

I added you to the project. You should now be able to push into the git repo. Let me know if you've got problems.

Marco

-------- Messaggio originale --------
Da: Vladimir Davydov <vda...@pa...> 
Data: 27/08/2013  09:37  (GMT+01:00) 
A: Marco Stornelli <mar...@gm...> 
Cc: pra...@li... 
Oggetto: Re: pramfstools 
 
On 08/26/2013 07:08 PM, Marco Stornelli wrote:
> Hi,
>
> Il 25/08/2013 20:28, Vladimir Davydov ha scritto:
>> Hello,
>>
>> I've written the fsck utility for PRAM FS. You can clone it from
>> git://github.com/locker/pramfstools
>>
>> Note that it requires read (write in case of repair) access to /dev/mem,
>> because AFAIK this is currently the only way to operate with PRAM FS
>> image, so STRICT_DEVMEM kernel config option must be turned off.
>>
>> Also note that currently it does not support PRAM FS xattrs, but I'm
>> planning to work this out.
>>
>> For more information and example of use cases, see README.
>>
>> I would appreciate if you could look at this. Perhaps it'll be worth
>> merging this to the PRAM FS repo at sourceforge if you find the code
>> acceptable, because IMHO it would be nice to have all the bits regarding
>> PRAM FS gathered in one place. Anyway, if you have any comments
>> regarding the tool's interface/coding style/etc, please let me know.
>>
>> Thanks.
>
> Great. A really good work. I create a new git repo:
>
> git clone git://git.code.sf.net/p/pramfs/Tools pramfs-Tools
>
> If you have got a sourceforge account I can add you to the project and 
> I can give you write access.

I've just joined :-) username is vdavydov825

> I didn't read the code in a deep way but my first comments:
>
> 1) I think it's a good idea to check at the beginning if the fs is 
> already mounted. On line check and repair can be dangerous. We can 
> read the proc files to know it;

Agree.

>
> 2) The pram_fs.h shouldn't be tracked in the repo. When you compile 
> you should have a reference in your kernel tree. Indeed this file 
> isn't in the private fs folder just for that;

Agree.

>
> 3) With the next version we have to change a couple of things: crc is 
> now 32 bit because it has got better performance and now the 
> structures are big enough to require a 32 bit crc.In addition I think 
> we have to manage the O_TMPFILE, we could have inode without any links 
> (but maybe this case is already covered in "orphaned inodes", I didn't 
> see it yet).

I guess check_orphaned_inodes() should handle O_TMPFILE properly 
although initially I implemented it for another reason. This is how FS 
tree check currently works:

1. Walk over FS tree starting from the root and descending to leafs 
marking all found inodes as 'reachable'

2. Iterate over the inode table checking if there are active (i.e. not 
deleted) inodes that are not marked as 'reachable' - I call them 
orphaned inodes. For each orphaned inode, first try to find its parent 
as specified by i_d.d_parent. If found, try to repair it, i.e. link back 
to the parent dir. If there is no active parent or parent link is 
invalid, prompt to delete it, because it's unrecoverable.

Initially, check for orphaned inodes was implemented, because PRAM FS 
directory entry structure is rather unreliable - corruption of an inode 
will result in loss of all inodes that follow it in the same directory. 
To avoid this, I try to recover inodes that were not found reachable.

However, this should also work for O_TMPFILE. AFAIU, O_TMPFILE is in 
fact the same as an open unlinked file, i.e. it has i_links_count=0 and 
i_d zeroed out, but i_dtime is not set and i_mode is not cleared yet so 
that it does not appear as deleted. So it won't be found and marked as 
'reachable' during walk over FS tree. Thus it will be later found as 
orphaned and unrecoverable since i_d.d_parent=0, and prompted to be 
deleted. The deletion won't free blocks allocated by the inode 
immediately, but the blocks should be freed in check_block_alloc() 
automatically, because they will also become orphaned with the deletion 
of the inode.

I will fix the code according to your comments above and notify you when 
it's done.

Thanks.

Re: [Pramfs-devel] pramfstools

[Marco S. <mar...@gm...>]

Hi,

Il 25/08/2013 20:28, Vladimir Davydov ha scritto:
> Hello,
>
> I've written the fsck utility for PRAM FS. You can clone it from
> git://github.com/locker/pramfstools
>
> Note that it requires read (write in case of repair) access to /dev/mem,
> because AFAIK this is currently the only way to operate with PRAM FS
> image, so STRICT_DEVMEM kernel config option must be turned off.
>
> Also note that currently it does not support PRAM FS xattrs, but I'm
> planning to work this out.
>
> For more information and example of use cases, see README.
>
> I would appreciate if you could look at this. Perhaps it'll be worth
> merging this to the PRAM FS repo at sourceforge if you find the code
> acceptable, because IMHO it would be nice to have all the bits regarding
> PRAM FS gathered in one place. Anyway, if you have any comments
> regarding the tool's interface/coding style/etc, please let me know.
>
> Thanks.

Great. A really good work. I create a new git repo:

git clone git://git.code.sf.net/p/pramfs/Tools pramfs-Tools

If you have got a sourceforge account I can add you to the project and I 
can give you write access. I didn't read the code in a deep way but my 
first comments:

1) I think it's a good idea to check at the beginning if the fs is 
already mounted. On line check and repair can be dangerous. We can read 
the proc files to know it;

2) The pram_fs.h shouldn't be tracked in the repo. When you compile you 
should have a reference in your kernel tree. Indeed this file isn't in 
the private fs folder just for that;

3) With the next version we have to change a couple of things: crc is 
now 32 bit because it has got better performance and now the structures 
are big enough to require a 32 bit crc. In addition I think we have to 
manage the O_TMPFILE, we could have inode without any links (but maybe 
this case is already covered in "orphaned inodes", I didn't see it yet).

Marco

[Pramfs-devel] R: RE: simple question

[marco <mar...@gm...>]

Old version are in the git repo. For 3.4, you can use the 1.3.4 version. There isn't any docs for installation with the exception of the file pramfs.txt copied under documentation folder of your kernel by the patch-ker.sh script. You can find there some usage tips.

Regards,

Marco

-------- Messaggio originale --------
Da: Brian Stark <sta...@at...> 
Data: 03/08/2013  20:02  (GMT+01:00) 
A: 'marco' <mar...@gm...>,pra...@li... 
Oggetto: RE: [Pramfs-devel] simple question 
 
Hi Marco,
 
Thanks for your quick reply,
 
a little background: 
 
I have been using pramfs-1.3.1-3.2 on kernel 3.0  Our systems got updated to kernel 3.4.12, when I tried to build the version of pramfs I was using I got several compile errors that appeared to be related to the new kernel.
 
I then downloaded pramfs-1.4.2-3.10, unfortunately when I ran the patch script the script failed because the uapi directory was not present in my kernel source, I am using 3.4 uapi did not get added until 3.7. (attached is the console log)
 
unfortunately, we are releasing software for kernel 3.4 and we cannot update our kernel for this release.
 
If there is an archived version of pramfs that was tested with 3.4 could you point me to it?  Also, is there any basic installation documentation I could refer too?
 
Thanks again,
 
Brian
 
CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited.  If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING.  Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina Corporation (or any of its subsidiaries), or any other person or entity.
 
 
 
From: marco [mailto:mar...@gm...] 
Sent: Thursday, August 1, 2013 11:12 PM
To: Brian Stark; pra...@li...
Subject: R: [Pramfs-devel] simple question
 
You have to patch your kernel using the script you can find in the repo and recompile. There isn't any distribution package. You have to choose the version for your kernel. When you have built your module, you can load it at startup.
 
Marco



-------- Messaggio originale --------
Da: Brian Stark <sta...@at...> 
Data: 02/08/2013 05:30 (GMT+01:00) 
A: pra...@li... 
Oggetto: [Pramfs-devel] simple question 


How do I install pramfs on Fedroa kernel 3.4.12?

------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Pramfs-devel mailing list
Pra...@li...
https://lists.sourceforge.net/lists/listinfo/pramfs-devel

Re: [Pramfs-devel] simple question

[Brian S. <sta...@at...>]

Hi Marco,

 

Thanks for your quick reply,

 

a little background: 

 

I have been using pramfs-1.3.1-3.2 on kernel 3.0  Our systems got updated to kernel 3.4.12, when I tried to build the version of pramfs I was using I got several compile errors that appeared to be related to the new kernel.

 

I then downloaded pramfs-1.4.2-3.10, unfortunately when I ran the patch script the script failed because the uapi directory was not present in my kernel source, I am using 3.4 uapi did not get added until 3.7. (attached is the console log)

 

unfortunately, we are releasing software for kernel 3.4 and we cannot update our kernel for this release.

 

If there is an archived version of pramfs that was tested with 3.4 could you point me to it?  Also, is there any basic installation documentation I could refer too?

 

Thanks again,

 

Brian

 

CONFIDENTIALITY

This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited.  If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.

ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING.  Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina Corporation (or any of its subsidiaries), or any other person or entity.

 

 

 

From: marco [mailto:mar...@gm...] 
Sent: Thursday, August 1, 2013 11:12 PM
To: Brian Stark; pra...@li...
Subject: R: [Pramfs-devel] simple question

 

You have to patch your kernel using the script you can find in the repo and recompile. There isn't any distribution package. You have to choose the version for your kernel. When you have built your module, you can load it at startup.

 

Marco




-------- Messaggio originale --------
Da: Brian Stark <sta...@at...> 
Data: 02/08/2013 05:30 (GMT+01:00) 
A: pra...@li... 
Oggetto: [Pramfs-devel] simple question 


How do I install pramfs on Fedroa kernel 3.4.12?

------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711 <http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk> &iu=/4140/ostg.clktrk
_______________________________________________
Pramfs-devel mailing list
Pra...@li...
https://lists.sourceforge.net/lists/listinfo/pramfs-devel

[Pramfs-devel] R: simple question

[marco <mar...@gm...>]

You have to patch your kernel using the script you can find in the repo and recompile. There isn't any distribution package. You have to choose the version for your kernel. When you have built your module, you can load it at startup.

Marco

-------- Messaggio originale --------
Da: Brian Stark <sta...@at...> 
Data: 02/08/2013  05:30  (GMT+01:00) 
A: pra...@li... 
Oggetto: [Pramfs-devel] simple question 
 
How do I install pramfs on Fedroa kernel 3.4.12?

------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Pramfs-devel mailing list
Pra...@li...
https://lists.sourceforge.net/lists/listinfo/pramfs-devel

[Pramfs-devel] simple question

[Brian S. <sta...@at...>]

How do I install pramfs on Fedroa kernel 3.4.12?

Re: [Pramfs-devel] mount hangs

[Michael N. <na...@ac...>]

Moving to LTSI is a good idea.  We have been using the kernel.org releases as our base, but LTSI might be a better choice.

- Michael

Re: [Pramfs-devel] mount hangs

[Marco S. <mar...@gm...>]

2012/12/20 Michael Nagy <na...@ac...>:
> Thanks Marco - The "Fixed double inode hashing in iget_locked path" fix did indeed resolve this problem!  We do plan on moving to a more recent kernel and fixlevel of pramfs, but it is nice to get it working at this level before moving on.
>
> - Michael
>

Great. You can consider to use the LTSI kernel. Pramfs is officially
included in this kernel (now the last release is 3.4.21).

Regards,

Marco

Re: [Pramfs-devel] mount hangs

[Michael N. <na...@ac...>]

Thanks Marco - The "Fixed double inode hashing in iget_locked path" fix did indeed resolve this problem!  We do plan on moving to a more recent kernel and fixlevel of pramfs, but it is nice to get it working at this level before moving on.

- Michael

-----Original Message-----
From: Marco Stornelli [mailto:mar...@gm...] 
Sent: Thursday, December 20, 2012 3:13 AM
To: Michael Nagy
Cc: pra...@li...
Subject: Re: [Pramfs-devel] mount hangs

2012/12/19 Michael Nagy <na...@ac...>:
> Simplified recreate sequence:
>
>    1) mount -t pramfs -o physaddr=0x21e00000,init=2M none /mnt/pram
>    2) umount
>    3) mount -t pramfs -o physaddr=0x21e00000,init=2M none /mnt/pram  <-- hangs
>
> After some tracing, the hang occurs in the call to iget_locked() in the pram_iget() procedure:
>
> struct inode *pram_iget(struct super_block *sb, unsigned long ino)
> {
>         struct inode *inode;
>         struct pram_inode *pi;
>         int err;
>         inode = iget_locked(sb, ino); // <-- hang occurs here
>
> I have verified that the sb (superblock) pointer and inode index are identical on both mount calls.
> Since this is post-initialization, I would assume the superblock content is also identical, but I will
> dig into that next.
>
> - Michael
>
>

Hi,

I really suggest you to use a recent version, there a lot of bug
fixes. For this kind of problem you can try to see the commit "Fixed
double inode hashing in iget_locked path".

Regards,

Marco

Re: [Pramfs-devel] mount hangs

[Marco S. <mar...@gm...>]

2012/12/19 Michael Nagy <na...@ac...>:
> Simplified recreate sequence:
>
>    1) mount -t pramfs -o physaddr=0x21e00000,init=2M none /mnt/pram
>    2) umount
>    3) mount -t pramfs -o physaddr=0x21e00000,init=2M none /mnt/pram  <-- hangs
>
> After some tracing, the hang occurs in the call to iget_locked() in the pram_iget() procedure:
>
> struct inode *pram_iget(struct super_block *sb, unsigned long ino)
> {
>         struct inode *inode;
>         struct pram_inode *pi;
>         int err;
>         inode = iget_locked(sb, ino); // <-- hang occurs here
>
> I have verified that the sb (superblock) pointer and inode index are identical on both mount calls.
> Since this is post-initialization, I would assume the superblock content is also identical, but I will
> dig into that next.
>
> - Michael
>
>

Hi,

I really suggest you to use a recent version, there a lot of bug
fixes. For this kind of problem you can try to see the commit "Fixed
double inode hashing in iget_locked path".

Regards,

Marco

Re: [Pramfs-devel] mount hangs

[Michael N. <na...@ac...>]

Simplified recreate sequence:

   1) mount -t pramfs -o physaddr=0x21e00000,init=2M none /mnt/pram
   2) umount
   3) mount -t pramfs -o physaddr=0x21e00000,init=2M none /mnt/pram  <-- hangs

After some tracing, the hang occurs in the call to iget_locked() in the pram_iget() procedure:

struct inode *pram_iget(struct super_block *sb, unsigned long ino)
{
	struct inode *inode;
	struct pram_inode *pi;
	int err;
	inode = iget_locked(sb, ino); // <-- hang occurs here

I have verified that the sb (superblock) pointer and inode index are identical on both mount calls.
Since this is post-initialization, I would assume the superblock content is also identical, but I will
dig into that next.

- Michael

Re: [Pramfs-devel] mount hangs

[Michael N. <na...@ac...>]

>>> Sorry - I am new to mailing lists.  Reformatted previous note to fit margins.

I am running the v1.2.5 level of pramfs on an older 2.6.37 kernel, and am encountering a problem trying
to implement conditional logic to determine if a prior pramfs filesystem is intact and initialize a new one
if it is not.  This basic sequence works fine:

   0) start with randomized SDRAM (after long power-off)
   1) mount -t pramfs -o physaddr=0x21e00000,init=0x200000 none /mnt/pramfs
   2) write some files to the /mnt/pramfs folder
   3) reboot
   4) mount -t pramfs -o physaddr=0x21e00000 none /mnt/pramfs
   5) verify files written in (2) are still there and intact

The problem is demonstrated with either of these sequences:

   0) start with randomized SDRAM (after long power-off)
   1) mount -t pramfs -o physaddr=0x21e00000 none /mnt/pramfs  <--  fails as expected
   2) mount -t pramfs -o physaddr=0x21e00000,init=0x20000 none /mnt/pramfs  <-- hangs

   0) start with randomized SDRAM (after long power-off)
   1) mount -t pramfs -o physaddr=0x21e00000 none /mnt/pramfs  <--  fails as expected
   2) umount /mnt/pramfs
   3) mount -t pramfs -o physaddr=0x21e00000,init=0x20000 none /mnt/pramfs  <-- hangs

I have verified that umount removes the mapping in /proc/iomap in the 2nd case.  It is odd that the failed
mount didn't remove the mapping itself as part of error cleanup - which is probably part of the issue somehow.

Anyhow, is this expected behavior?  Is it a problem that has been fixed moving forward from the older
code-base I am building from (v1.2.5)?  Any other suggestions on how to debug or resolve?

- Michael

[Pramfs-devel] mount hangs

[Michael N. <na...@ac...>]

I am running the v1.2.5 level of pramfs on an older 2.6.37 kernel, and am encountering a problem trying to implement conditional logic to determine if a prior pramfs filesystem is intact and initialize a new one if it is not.  This basic sequence works fine:

   0) start with randomized SDRAM (after long power-off)
   1) mount -t pramfs -o physaddr=0x21e00000,init=0x200000 none /mnt/pramfs
   2) write some files to the /mnt/pramfs folder
   3) reboot
   4) mount -t pramfs -o physaddr=0x21e00000 none /mnt/pramfs
   5) verify files written in (2) are still there and intact

The problem is demonstrated with either of these sequences:

   0) start with randomized SDRAM (after long power-off)
   1) mount -t pramfs -o physaddr=0x21e00000 none /mnt/pramfs  <--  fails as expected
   2) mount -t pramfs -o physaddr=0x21e00000,init=0x20000 none /mnt/pramfs  <-- hangs

   0) start with randomized SDRAM (after long power-off)
   1) mount -t pramfs -o physaddr=0x21e00000 none /mnt/pramfs  <--  fails as expected
   2) umount /mnt/pramfs
   3) mount -t pramfs -o physaddr=0x21e00000,init=0x20000 none /mnt/pramfs  <-- hangs

I have verified that umount removes the mapping in /proc/iomap in the 2nd case.  It is odd that the failed mount didn't remove the mapping itself as part of error cleanup - which is probably part of the issue somehow.

Anyhow, is this expected behavior?  Is it a problem that has been fixed moving forward from the older code-base I am building from (v1.2.5)?  Any other suggestions on how to debug or resolve?

- Michael

Re: [Pramfs-devel] [PATCH] Fix CONFIG_PRAMFS_WRITE_PROTECT disabled prevents XIP

[Marco S. <mar...@gm...>]

2012/11/23 Håkan Lindqvist <hak...@en...>:
>> -----Original Message-----
>> From: Marco Stornelli [mailto:mar...@gm...]
>> Sent: den 22 november 2012 17:31
>> To: Håkan Lindqvist
>> Cc: pra...@li...
>> Subject: Re: [PATCH] Fix CONFIG_PRAMFS_WRITE_PROTECT disabled
>> prevents XIP
>>
>> Il 22/11/2012 15:07, Håkan Lindqvist ha scritto:
>> > We found a small bug in the build option handling that prevents the
>> > use of the XIP feature when built with the option
>> CONFIG_PRAMFS_WRITE_PROTECT disabled.
>> >
>> > This patch fixes this  when applied to latest
>> >
>>
>> Thanks for the patch, I agree with you. However I think the latest #ifdef is
>> redundant because if protection is not compiled you can't do anything with
>> mount options and if it's not set by set_default_opts(), the option has to be
>> off, so the test with xip will be always ok.
>>
>> Marco
> I Agree, the second #ifdef is redundant from a functionality standpoint. It is
> included because I got the impression that the purpose of the build option
> is not only to reduce functionality but also to remove code that is inert with
> that option. I can resend the patch without the second #ifdef if this is
> preferable.
>
> Best regards / Håkan Lindqvist

Yep, I agree. However for the kernel coding style, the #ifdef should
be present in .h. So I prefer to avoid if possible not needed #ifdef
in .c file. If you can resend it on top of my tree I'll be happy to
apply it.

Regards,

Marco

Re: [Pramfs-devel] [PATCH] Fix CONFIG_PRAMFS_WRITE_PROTECT disabled prevents XIP

[Marco S. <mar...@gm...>]

Il 22/11/2012 15:07, Håkan Lindqvist ha scritto:
> We found a small bug in the build option handling that prevents the use of the
> XIP feature when built with the option CONFIG_PRAMFS_WRITE_PROTECT disabled.
>
> This patch fixes this  when applied to latest
>

Thanks for the patch, I agree with you. However I think the latest 
#ifdef is redundant because if protection is not compiled you can't do 
anything with mount options and if it's not set by set_default_opts(), 
the option has to be off, so the test with xip will be always ok.

Marco

[Pramfs-devel] correlating git guid's with version numbers

[Charles K. <cha...@gm...>]

Dear Marco:

On your sourceforge project, you have version tags for 1.2.5 through
1.2.8, You also have about 100 checkins from the beginning of your
source tree all identified with 160bit guid's.

I have figured out how to get a particular version by guid. I can also
use the guid for that version to checkout the source.

The question is "Is there a way to use git to obtain the pramfs source
by version tag instead of by guid from the pramfs repository and if
so, what is the recipe, please?"

-- 
Charles Krinke

Re: [Pramfs-devel] Making progress (I think)

[Marco S. <mar...@gm...>]

Il 05/05/2012 19:08, Charles Krinke ha scritto:
> Dear Marco:
>
> I have worked out how to get a particular revision from pramfs git.
> The recipe is:
> $ git init
> $ git pull git://pramfs.git.sourceforge.net/gitroot/pramfs/pramfs
> $ git log --pretty=oneline
> Select the second from the earliest that contains
> 876f8222bb922fbac7be819dabd8c62713dbb19a Fix bug number 3141759 and
> 3141762
> $ git checkout 876f8222bb922fbac7be819dabd8c62713dbb19a
>
> I then take this source along with the latest (head) pram_fs.h and
> pram_fs_sb.h in include/linux do a make. At this point, there are 5
> issues in compiling the source into the 2.6.35.12 kernel.
>
> inode.c:453 implicit end_writeback  //comment for now
> inode.c:714 implicit setattr_copy     //use generic_setattr
> super.c:819 unknown evict_inode
> super.c:829 implicit mount_nodev
> super.c:835 unknown field mount
>
> It looks at this point that the end_writeback, evict_inode,
> mount_nodev and mount initializer are not part of the 2.6.25.12 kernel
> and need to be handled a different way that the 1.2.0 tarball did with
> pramfs for the 2.6.35.12 kernel.
>
> I guess the question of the moment is "Is this a reasonable path" and
> if so, how would we suggest handling the unresolveds in the 2.6.35.12
> kernel.
>

There are two ways:

1) You know exactly what you are doing and solve the problems without 
copy&paste but re-thinking about the solution and (most important) you 
have to know the roles of that functions and the kernel changes 
"history". I don't think the right thing to do is "it doesn't compile so 
I comment it".

2) As I already answered, take patch for 2.6.35 and fix only the 
important things. I gave you the list. In addition you can find the list 
of what I did in git, so you can decide what it can be backported and 
what not. At this point if you want to follow my tips ok, if you don't 
want to follow any kind of tips then you can avoid to write here.

I don't provide any kind of step-by-step support. Avoid to fix things 
for older versions is a project choice, but as the code is all open 
source, each developer can follow the philosophy "do-it-yourself". I 
don't want to be unkindly, but I don't provide a "customer support" 
service, if you have got a particular problem then I can solve it with 
you as I did for other bugs reported from other developers/companies, 
but I can't follow you step-by-step. The black-box approach (I don't 
know what it does and I don't want to know it, if I have a problem I'll 
call the customer support) doesn't work for an open source project. Sorry.

Marco