On Fri, 9 Jun 2000, Anton Altaparmakov wrote:
> after running: find . -type f -exec md5sum {} \; on a NTFS partition,
> _sometimes_ I get the following from bash:
>
> find: cannot fork: Cannot allocate memory
This means the kernel cannot find an 8kB contiguous (2 pages)
area of memory ... this shouldn't happen and I haven't been able
to reproduce it here even under heavy stress conditions (without
ntfs).
The extremely high number of buffers, however, makes me suspect
that something (the NTFS driver?) makes the buffers unfreeable
so shrink_mmap cannot succeed in freeing the pages, this would
cause exactly the memory fragmentation the fork error indicates.
> However looking at free shows plenty of memory in buffers which
> could be freed - which might be not happening of course?
If you read mm/filemap.c::shrink_mmap(), you'll find a call to
try_to_free_buffers(). That call is run on just about every page
with buffers that we encounter (this usually results in us freeing
the page).
However, if try_to_free_buffers() (from fs/buffer.c) fails because
the filesystem is doing strange things with the buffer state, then
we'll be in deep shit ...
> What I am wondering about is whether this is a NTFS bug at all.
> - It could be a bug somewhere else which gets triggered by the
> high load that NTFS driver causes. -
It could be anything, but the fact that I've never witnessed
such a high amount of buffer pages with ext2 tests makes the
NTFS driver primary suspect ...
regards,
Rik
-- The Internet is not a network of computers. It is a network of people. That is its real strength.Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies http://www.conectiva.com/ http://www.surriel.com/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:19 EST