VxWorks (?) Flash File System on the MERs

Does anybody have more technical info, or pointers to such, on the flash
file system used by the MERs? The reason I ask is that JPL's explanation
for Spirit's problem states that mounting such a file system uses system
memory proportional to the number of files in it - at least, that seems
to be the leading theory supported by experimentation. It would be the
first file system I know of with that property, but perhaps the requirement
to reduce write cycles on the flash lead to it. It also seems strange that
the MER software engineers have so little understanding on exactly how
the flash file system works that they cannot say with authority whether
this theory is correct or not.

Jan

In article ,
Jan C. =?iso-8859-1?Q?Vorbr=FCggen?= wrote:
...It also seems strange that
the MER software engineers have so little understanding on exactly how
the flash file system works that they cannot say with authority whether
this theory is correct or not.

VxWorks is *not* an open-source system, so if the docs don't happen to
discuss this issue...
--
MOST launched 30 June; science observations running | Henry Spencer
since Oct; first surprises seen; papers pending. |

In article , Jan C. Vorbrüggen wrote:
Does anybody have more technical info, or pointers to such, on the flash
file system used by the MERs? The reason I ask is that JPL's explanation
for Spirit's problem states that mounting such a file system uses system
memory proportional to the number of files in it - at least, that seems
to be the leading theory supported by experimentation. It would be the
first file system I know of with that property, but perhaps the requirement
to reduce write cycles on the flash lead to it. It also seems strange that
the MER software engineers have so little understanding on exactly how
the flash file system works that they cannot say with authority whether
this theory is correct or not.

When your software is at Mars, you really don't have a very good
way of debugging it. And it is rather common for filesystems to do this.
It basically works like if you call opendir or readdir the kernel
reads the inode for that directory. That inode contains "pointers"
to all its files, if it's alot of files... it gets big.

--
Vennlig hilsen/Best Regards
Nils Olav Selåsdal NOS at Utel.no
System Engineer
UtelSystems a/s

Does anybody have more technical info, or pointers to such, on the flash
file system used by the MERs? The reason I ask is that JPL's explanation
for Spirit's problem states that mounting such a file system uses system
memory proportional to the number of files in it - at least, that seems
to be the leading theory supported by experimentation. It would be the
first file system I know of with that property, but perhaps the
requirement
to reduce write cycles on the flash lead to it. It also seems strange
that
the MER software engineers have so little understanding on exactly how
the flash file system works that they cannot say with authority whether
this theory is correct or not.

Jan



Someone posted these links on another group a week or so ago:

http://www.windriver.com/products/true_ffs/trueffs.pdf

http://www.m-sys.com/files/documenta...QRG_Rev1.3.pdf

We know that they are using VxWorks, but whether they are using the
M-Systems flashdisks, or some other linear flash technology is another
question. The M-Systems devices unburden the OS considerably, but other
flash architectures could certainly have an impact on system memory
(RAM). Since the rover is not an open source project, the public is not
invited to review the design.

Any reputable RTOS (Real Time Operating System) vendor will specify memory
requirements for their file systems. I am inclined to believe that the
rover problem is subtle. For example, if there were a low priority
process responsible for performing periodic integrity checks on all the
files, a large number of files could have unforseen consequences.

We (the public) just have to sit back and wait for Spirit to deliver its
lesson on RTOS system design.

Eric

Jan C. =?iso-8859-1?Q?Vorbr=FCggen?= wrote:

Does anybody have more technical info, or pointers to such, on the flash
file system used by the MERs? The reason I ask is that JPL's explanation
for Spirit's problem states that mounting such a file system uses system
memory proportional to the number of files in it - at least, that seems
to be the leading theory supported by experimentation. It would be the
first file system I know of with that property, but perhaps the requirement
to reduce write cycles on the flash lead to it. It also seems strange that
the MER software engineers have so little understanding on exactly how
the flash file system works that they cannot say with authority whether
this theory is correct or not.

I apologize for not having any technical data myself.

However, I found that statement by NASA (more memory for more files)
quite odd myself. Generally speaking, you want to keep the meta-data
(filename, creation time, size, etc.) in the same non-volatile storage
as the file itself.

It is probably a matter of reporters not understanding technical issues
the engineers don't fully understand (or can explain) themselves.

James Graves

Henry Spencer wrote:
In article ,
Jan C. =?iso-8859-1?Q?Vorbr=FCggen?= wrote:
...It also seems strange that
the MER software engineers have so little understanding on exactly how
the flash file system works that they cannot say with authority whether
this theory is correct or not.

VxWorks is *not* an open-source system, so if the docs don't happen to
discuss this issue...

And the docs are not freely available either, AIUI.

(Henry Spencer) wrote:
In article ,
Jan C. =?iso-8859-1?Q?Vorbr=FCggen?= wrote:
...It also seems strange that
the MER software engineers have so little understanding on exactly how
the flash file system works that they cannot say with authority whether
this theory is correct or not.

VxWorks is *not* an open-source system, so if the docs don't happen to
discuss this issue...

Clarification: access to the VxWorks source code is available if you pay
for it. It seems reasonable to believe that access to the source code would
have been purchased. The need for an application developer to have to
understand it is another story.

I've sat through at least two sales pitches from Wind River sales teams at
two startups that evaluated RTOSs for their products (these pitches
happened several years ago - one company went with LynxOS and the other
with WxWorks. The LynxOS was the pre-Linux version for those who know about
that RTOS). Wind River salesmen always made sure to mention the Mars
Pathfinder mission and how their debugging (and remote upload) tools saved
the day. They also charge through the nose relative to other RTOSs.