Discussion:
newbie to JFFS2
Srivatsan
2005-03-27 11:48:55 UTC
Permalink
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 ***@axis.com
Artem B. Bityuckiy
2005-03-28 07:00:32 UTC
Permalink
Post by Srivatsan
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
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.
Post by Srivatsan
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'm not sure I understand your question. Versions are the crucial part
of JFFS2 and JFFS2 design. Versions are invisible for users and are an
element of internal JFFS2 design.
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.


To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to ***@axis.com
Srivatsan
2005-03-28 08:14:19 UTC
Permalink
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:***@infradead.org]
Sent: Monday, March 28, 2005 12:31 PM
To: Srivatsan
Cc: jffs-***@axis.com
Subject: Re: newbie to JFFS2
Post by Srivatsan
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
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.
Post by Srivatsan
2) Is anyone using versioning alongwith JFFS2? If so, have you
modified
Post by Srivatsan
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'm not sure I understand your question. Versions are the crucial part
of JFFS2 and JFFS2 design. Versions are invisible for users and are an
element of internal JFFS2 design.
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to ***@axis.com
Artem B. Bityuckiy
2005-03-28 08:40:33 UTC
Permalink
Post by Srivatsan
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.
Post by Srivatsan
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.
Post by Srivatsan
3) Does www.embeddedlinuxworks.com still exists or has it relocated?
I Have no Idea.
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.


To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to ***@axis.com
Srivatsan
2005-03-28 16:38:11 UTC
Permalink
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 ***@axis.com

Michael Richardson
2005-03-28 16:24:47 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
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"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQkgvzYqHRg3pndX9AQGAzAP/cF8sAOJNnXNWsxOO9VCxhwLIRsbpEP3k
CTTbsW/BLkNh90uitufLysnnRzeobPDh04hkqbUeA0W8/f7uoPW27UTucG/ODNot
fBPqv/S6+WLvrzQcHqNnhwOKHXhBvsoRdkH4w6RlbLF8BSF5bYcB+tkkW4AhKMMe
tAxjH9Po/E4=
=UifP
-----END PGP SIGNATURE-----

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to ***@axis.com
Michael Richardson
2005-03-28 16:22:24 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
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"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQkgvP4qHRg3pndX9AQHArAP/Vtmz00RWgLlH6RD1E+wGreH1uipMinq5
eRgZo0pN9ULF6iXi6uoL6kLYBU3M0LrPBkiFilfwC71AsTDE9nBFXggn7wuHgom6
5vF0e7Z9nM2AwMv2yYMGV+8gKnwnSOWwyJ4dNVTCc9n2vejtKUfdh01VkP7/sJoU
6r79iB0XoOo=
=FcAk
-----END PGP SIGNATURE-----

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to ***@axis.com
Loading...