[OpenAFS-devel] reproducible problem during cache flush

[Neulinger, Nathan]

Woohoo!

Do you think this would be at all an issue if the cache were larger?
i.e. could this scenario occur on a system with a more reasonably sized
cache?

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216


> -----Original Message-----
> From: Nickolai Zeldovich [mailto:kolya@MIT.EDU]=20
> Sent: Tuesday, July 30, 2002 12:10 PM
> To: openafs-devel@openafs.org
> Subject: Re: [OpenAFS-devel] reproducible problem during cache flush
>=20
>=20
> I was also able to reproduce the problem on my machine (2.4.18, SMP,
> even though I don't think SMP matters here).  The problem is, as we
> already suspected, the small cache.  The writing process is hung in
> afs_UFSWrite in afs_osi_Sleep(&afs_WaitForCacheDrain).  The cache
> truncate daemon is unable to clean up anything because all the
> dcaches are either IFFree (on the free list) or IFDataMod (have
> unsaved data), and keeps looping.
>=20
> It looks like the old 2.2 Linux code called afs_DoPartialWrite to
> flush modified chunks if we were running low on cache space, but
> the new 2.4 VM-integrated write routines, that use generic_file_write,
> don't call afs_DoPartialWrite anywhere.  This is likely the problem.
>=20
> -- kolya
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>=20