headers
Cian Masterson | 16 Mar 19:29

Problems writing to an area of Flash not covered by jffs2 partition.

Hi,

I'm trying to directly update a value in an area of Flash not covered by 
my jffs2 partition and am hitting problems.  Once I've written to the 
flash I get the following errors popping up whenever I try to type 
anything on the board:

root@(none):~# 
ls                                                              
Node CRC 00800080 != calculated CRC f62bca25 for node at 
002f2ee8              
bash: /bin/ls: Input/output 
error                                              
root@(none):~#

Reboot the board and everthing is hunky dory so it doesn't look like any 
damage is done.  I am using a 256MB Intel StrataFlash part and I'm 
thinking the problem lies with unlocking the flash.  According to the 
Intel Datasheet the lock bits for all blocks in flash are unlocked 
simultaneously by the one command, so when I go to unlock my little 
section of Flash I actually unlock all of it.  I'm assuming that this is 
messing up the CRCs for each node, but am new to jffs2 so can't be 
sure.  I have previously written to the OTP section of flash without 
problems, however since it uses special write commands (write 0xC0 to 
flash followed by data to specific protection register address) I figure 
it doesn't affect the jffs2 filesystem at all.

Has anyone ever seen this or can anyone tell me whether my assumptions 
about unlocking above are correct?  Failing that does anyone have any 
notion how I can program to a separate area of Flash without corrupting
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jesper Juhl | 25 Mar 23:18
Picon

[PATCH] get rid of redundant checks for NULL before kfree() in fs/jffs/


There's no need to check for NULL before calling kfree().

Signed-off-by: Jesper Juhl <juhl-lkml <at> dif.dk>

--- linux-2.6.12-rc1-mm3-orig/fs/jffs/intrep.c	2005-03-21 23:12:41.000000000 +0100
+++ linux-2.6.12-rc1-mm3/fs/jffs/intrep.c	2005-03-25 22:47:29.000000000 +0100
@@ -1693,9 +1693,7 @@ jffs_find_child(struct jffs_file *dir, c
 		}
 		printk("jffs_find_child(): Didn't find the file \"%s\".\n",
 		       (copy ? copy : ""));
-		if (copy) {
-			kfree(copy);
-		}
+		kfree(copy);
 	});

 	return f;
Permalink | Reply | 0 comments |
headers
Srivatsan | 27 Mar 13:48

newbie to JFFS2


Dear all,

    I am new to the concept of Flash File System. I had gone thro' the
JFFS2 white paper and to an extent the source code of JFFS2. I have the
following doubt:

1) I am seeing that the filenames are not being stored along with the
inode but with dentry nodes? If I want to make nodes self referential
(inode number and filename in the same raw inode structure), is it
possible? I was trying to go thro' the JFFS source, but their again the
file names are not stored in the JFFS_raw_inode structure (but in the
white paper it is mentioned that filenames are stored along with the
metadata). Can anyone please clarify exactly how filenames are being
handled in JFFS2? Really it would be a great help to me.

2) Is anyone using versioning alongwith JFFS2? If so, have you modified
the exisiting JFFS2 source or are you using concepts like stackable file
system to achieve your requirements? If possible, can you experience be
shared.

I thanks all of you for patiently going thro' my mail. 

With best regards,
C.R.Srivatsan

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo <at> axis.com
(Continue reading)

Permalink | Reply | 6 comments |
headers
Artem B. Bityuckiy | 28 Mar 09:00
Favicon

Re: newbie to JFFS2

On Sun, 2005-03-27 at 17:18 +0530, Srivatsan wrote:
> Dear all,
> 
>     I am new to the concept of Flash File System. I had gone thro' the
> JFFS2 white paper and to an extent the source code of JFFS2. I have the
> following doubt:
> 
> 1) I am seeing that the filenames are not being stored along with the
> inode but with dentry nodes? If I want to make nodes self referential
> (inode number and filename in the same raw inode structure), is it
> possible? I was trying to go thro' the JFFS source, but their again the
> file names are not stored in the JFFS_raw_inode structure (but in the
> white paper it is mentioned that filenames are stored along with the
> metadata). Can anyone please clarify exactly how filenames are being
> handled in JFFS2? Really it would be a great help to me.
There is a model sometimes called "VFS model" where data is represented
by means of inode objects while names are represented by directory
entries. Inodes contain all the file's (direcory's) data and metadata
(permissions, etc). One inode may be referred by several directory
entries and this allows us to have hardlinks. And this is common model,
not JFFS2-specific.

Do you want to join them? Then you'll end up with FAT which is avoid of
hardlinks.

> 
> 2) Is anyone using versioning alongwith JFFS2? If so, have you modified
> the exisiting JFFS2 source or are you using concepts like stackable file
> system to achieve your requirements? If possible, can you experience be
> shared.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Srivatsan | 28 Mar 10:14

RE: newbie to JFFS2

Thanks Mr. Artem. Please excuse me if I am asking too obvious questions.

1) I have a requirement in my software to make the filesystem self 
   referential. For this I had gone thro' JFFS source code and also
JFFS2 
   source code. But the problem is that the filename representations are

   made in the RAM based structures rather than the in flash data 
   structures. How is the File System getting the Filename while it is
being 
   built in JFFS? In our design we are not particular to support
hardlinks.

2) What I meant by versioning is the version for each file (e.g., CVS)
being 
   stored on the file system. If anybody can give me a case study of how

   they have done this, might be very useful to me. 

3) Does www.embeddedlinuxworks.com still exists or has it relocated? 

With Regards,
C.R.Srivatsan

-----Original Message-----
From: Artem B. Bityuckiy [mailto:dedekind <at> infradead.org] 
Sent: Monday, March 28, 2005 12:31 PM
To: Srivatsan
Cc: jffs-dev <at> axis.com
Subject: Re: newbie to JFFS2
(Continue reading)

Permalink | Reply | 3 comments |
headers
Artem B. Bityuckiy | 28 Mar 10:40
Favicon

RE: newbie to JFFS2

On Mon, 2005-03-28 at 13:44 +0530, Srivatsan wrote:
> Thanks Mr. Artem. Please excuse me if I am asking too obvious questions.
> 
> 1) I have a requirement in my software to make the filesystem self 
>    referential. For this I had gone thro' JFFS source code and also
> JFFS2 
>    source code. But the problem is that the filename representations are
> 
>    made in the RAM based structures rather than the in flash data 
>    structures. How is the File System getting the Filename while it is
> being 
>    built in JFFS? In our design we are not particular to support
> hardlinks.
Names are stored within the filesystem on flash media in the dirent
nodes. They may be cached in RAM, but are read from flash to the cache.

> 
> 2) What I meant by versioning is the version for each file (e.g., CVS)
> being 
>    stored on the file system. If anybody can give me a case study of how
> 
>    they have done this, might be very useful to me. 
JFFS2 doesn't know anything about user-level versions like CVS. For
JFFS2 as for any other file-system I know all files are treated equally.
JFFS2 uses versions of *nodes* (not files) internally and this is not
the business of user-space applications.

> 3) Does www.embeddedlinuxworks.com still exists or has it relocated? 
I Have no Idea.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Richardson | 28 Mar 18:24
Picon

Re: newbie to JFFS2


>>>>> "Srivatsan" == Srivatsan  <srivatsan <at> deccanetworld.com> writes:
    Srivatsan> 1) I have a requirement in my software to make the
    Srivatsan> filesystem self referential. For this I had gone thro'
    Srivatsan> JFFS source code and also JFFS2 source code. But the
    Srivatsan> problem is that the filename representations are

  You'll have to explain what this means, and why you care about it.
  It could mean a hundred different things to different people. It could
be as simple as having a device node in the JFFS2 file system which
refers to the JFFS2 device. 

    Srivatsan> 2) What I meant by versioning is the version for each
    Srivatsan> file (e.g., CVS) being stored on the file system. If
    Srivatsan> anybody can give me a case study of how
    Srivatsan>    they have done this, might be very useful to me.

  Generally, you should avoid doing all of this in a single file system.

  Instead, layer another file system on top of JFFS2.
You may want to look at Sun "Translucent File system", or BSD's "union"
file systems. 

--

-- 
] Michael Richardson          Xelerance Corporation, Ottawa, ON |  firewalls  [
] mcr @ xelerance.com           Now doing IPsec training, see   |net architect[
] http://www.sandelman.ca/mcr/    www.xelerance.com/training/   |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
Permalink | Reply | 0 comments |
headers
Michael Richardson | 28 Mar 18:22
Picon

Re: newbie to JFFS2


>>>>> "Artem" == Artem B Bityuckiy <dedekind <at> infradead.org> writes:
    Artem> There is a model sometimes called "VFS model" where data is
    Artem> represented by means of inode objects while names are
    Artem> represented by directory entries. Inodes contain all the
    Artem> file's (direcory's) data and metadata (permissions, etc). One
    Artem> inode may be referred by several directory entries and this
    Artem> allows us to have hardlinks. And this is common model, not
    Artem> JFFS2-specific.

    Artem> Do you want to join them? Then you'll end up with FAT which
    Artem> is avoid of hardlinks.

  FAT has all sorts of other stupids other than that, but I agree. leave
the stuff along.

  If you want to create a directory that contains itself, that's
easy. Just force a hard link. "." is already such a directory, but
perhaps you would be happy with a symbolic link.

  Creating a file that contains itself is meaningless.

--

-- 
] Michael Richardson          Xelerance Corporation, Ottawa, ON |  firewalls  [
] mcr @ xelerance.com           Now doing IPsec training, see   |net architect[
] http://www.sandelman.ca/mcr/    www.xelerance.com/training/   |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
Permalink | Reply | 0 comments |
headers
Srivatsan | 28 Mar 18:38

RE: newbie to JFFS2

Thanks Mr.Michael.

Our software requirement is such that we need a self referential file
system. We are in the development of a very critical system and out
architect feels that there is a room for failure while the filesystem is
trying to retrieve the filename from the dentry data structure
(eventually the data is there but the block storing the filename has
gone bad). So it has been decided that Filenames shall be stored along
with the inode numbers in the same structure so that each node can have
the filename field stored.

For this idea, I had gone thro JFFS(v1) source code but the filename are
not stored along with the inode number but they are stored in the
overall filesystem control structure (jffs_control). But in the white
paper it is mentioned that filenames are stored along with the metadata?
Which is right? Thanks again.  

Hope I have clarified my point. 

With Regards,
C.R.Srivatsan

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo <at> axis.com
Permalink | Reply | 0 comments |

Gmane