RE: jffs2_scan_eraseblock() - errors

RE: jffs2_scan_eraseblock() - errors

[Curtis, Allen]

> >  INOCACHE_HASHSIZE was set to 1. Changed this to 128 and....
> > real	47.258s sys	47.25s
> 
> It's the first (and easy) part of the proof-of-concept which involves 
> moving said CRC32 check to later so the mount doesn't have to 
> wait for it.

With the CRC patch:
real	36.7s

PS: The version of scan.c we are using is 1.57. The patch note was for
1.51.2.3.

Re: jffs2_scan_eraseblock() - errors

[David Woodhouse]

(Moved to JFFS list).

Allen.Curtis@Thales-IFS.com said:
> > real	47.258s

>  With the CRC patch:
>  real	36.7s

OK, that's respectable. I just need to finish the other part of the change 
-- to actually check the CRCs later on, rather than just leaving them 
unchecked. Make sure you take the patch back out of your tree now :)

We may get a little bit more of a speedup when we do that too, as we'll also
stop building up the fragment lists for every inode on mount, but in fact
that code wasn't showing up very high on the profile last time I looked.

> PS: The version of scan.c we are using is 1.57. The patch note was for
> 1.51.2.3.

Doesn't matter; it's basically the same in both branches. 

I suspect that if you profile it now you'll find the most time is taken in 
your flash map driver's copy_from routine or memcpy. 

I need to implement the XIP scheme which will also allow JFFS2 to directly
access the flash through a kind of pageable ioremap (which handles the times
when the flash is in a mode other than read mode correctly) instead of 
having to read into a buffer and work from that. We get to use caches and 
burst reads from flash at that point too.

--
dwmw2

write suspend and/or erase suspend

[Joakim Tjernlund]

When a erase or write is suspened to allow some other part of the FS to read, is that read
garanted to read from another sector than the one that has been suspended?

I am asking since I think it's not allowed to access the sector that has a 
suspended operation. I am using Intel Strata Flash.

   Jocke

Re: write suspend and/or erase suspend

[David Woodhouse]

Joakim.Tjernlund@lumentis.se said:
> When a erase or write is suspened to allow some other part of the FS
> to read, is that read garanted to read from another sector than the
> one that has been suspended?

> I am asking since I think it's not allowed to access the sector that
> has a  suspended operation. I am using Intel Strata Flash. 

Correct. Currently we don't suspend writes, but when we do we need to make 
sure we get that right. Reading from a block on which an erase is in 
progress is a silly idea anyway, so I don't care that we don't check for 
that and make the reader wait.

--
dwmw2

Re: write suspend and/or erase suspend

[Joakim Tjernlund]

From: "David Woodhouse" <dwmw2@infradead.org>
> 
> Joakim.Tjernlund@lumentis.se said:
> > When a erase or write is suspened to allow some other part of the FS
> > to read, is that read garanted to read from another sector than the
> > one that has been suspended?
> 
> > I am asking since I think it's not allowed to access the sector that
> > has a  suspended operation. I am using Intel Strata Flash. 
> 
> Correct. Currently we don't suspend writes, but when we do we need to make 
> sure we get that right. Reading from a block on which an erase is in 
> progress is a silly idea anyway, so I don't care that we don't check for 
> that and make the reader wait.

Yes, it's silly but can it happen by mistake? The flash state machine may be 
confused if an access is made during suspend. 

hmm, my modified driver also supports "suspend erase to do a write". Could that be a problem? 

> 
> --
> dwmw2
> 
> 

Re: write suspend and/or erase suspend

[David Woodhouse]

Joakim.Tjernlund@lumentis.se said:
>  Yes, it's silly but can it happen by mistake? The flash state machine
> may be  confused if an access is made during suspend. 

You'll get a buffer full of status bits, I expect. Doesn't matter -- the 
contents of the block at that time are undefined because they're in the 
middle of an erase.

> hmm, my modified driver also supports "suspend erase to do a write".
> Could that be a problem? 

Again, only if someone's trying to write to a block they're currently 
trying to erase -- which they shouldn't be doing.

We _should_ be checking for these things in the driver, and we _definitely_ 
have to do so before start suspending writes to perform reads. But at the 
moment, the only way a user could trigger wrong behaviour is if they're 
doing something bloody stupid anyway.


--
dwmw2