long umount time

long umount time

[Sergei Sharonov]

Hi,
I sometimes see excessively long umount times (40-60 s) with jffs2/nand. 
The platform is a custom at91rm9200 board running linux 2.6.10 with 
mtd snapshot from 3/28/2005. Umount is from busybox. The umount time varies
but the system is mostly idle during it unlike during mount. After a few
operations with filesystem it goes away until sometime later. Has anybody 
seen that?

Sergei Sharonov

Re: long umount time

[Artem B. Bityuckiy]

On Wed, 6 Apr 2005, Sergei Sharonov wrote:

> Hi,
> I sometimes see excessively long umount times (40-60 s) with jffs2/nand. 
> The platform is a custom at91rm9200 board running linux 2.6.10 with 
> mtd snapshot from 3/28/2005. Umount is from busybox. The umount time varies
> but the system is mostly idle during it unlike during mount. After a few
> operations with filesystem it goes away until sometime later. Has anybody 
> seen that?
>
I see 2 reasons why umounts can be slow:
1. The GC thread receives several SIGHUP signals and JFFS2 waits for 
the GC thread has processed them all and has reached the SIGKILL signal.

2. The final wbuf synchronization founds that there is no space and 
performs GC to free some room. We may imagine scenarios when this may take 
considerable time.

Please, look at jffs2_gcd_mtd thread - does it eat a lot of CPU cycles 
during these long unmounts ?

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: long umount time

[Sergei Sharonov]

Hi,

> Please, look at jffs2_gcd_mtd thread - does it eat a lot of CPU cycles 
> during these long unmounts ?
I got the board in the oven running endurance test again.. I'll post results
once I get hardware back. I got prior results captured in text file with
Hyperterminal but the bloody thing has messed the text file (Dah!). From
what I recall user and system times were close to 0, so I suppose nothing
was eating CPU cycles.

Sergei Sharonov