Re: 2.1.110 freepages.min change

Trever Adams (highlander@teleteam.net)
Thu, 23 Jul 1998 00:25:10 -0500

> '0' is actually the same as "infinite", if you look at the code. So a
> "prune_dcache(0)" will prune _all_ of the unused entries, while for
> example a "prune_dcache(10)" will prune just 10 entries.
>
> Essentially the new logic is that if we didn't find anything else that
> can easily be free'd, we just prune the _whole_ dcache. That either
> happens very seldom indeed (on my machine ;), or if it happens often it
> just means that the machine is low on memory in which case it is
> entirely reasonable to throw away the dcache aggressively.
>
> Linus

I saw a post asking about disk corruption (which unfortunately means I
don't try that kernel since I don't have a box that I can risk a known
chance on). I have yet to see a reply. I am not a guru of the kernel
(trying, but time is needed elsewhere), but the first thing that came to
mind was the dcache pruning. The next thing that came to mind was the
vmalloc bug.

My questions are simple: If the inode/file/whatever that the dcache
entry referred to is still open and being used, or hasn't yet been
synched to disk and is "closed" and that dcache entry is pruned,
does/can it cause disk corruption or data corruption in the file. Q.
#2, Could the disk corruption that a few people have reported be caused
by the bad patch to vmalloc (at least I believe that was the malloc
involved)?

Trever Adams
highlander@teleteam.net

-
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.altern.org/andrebalsa/doc/lkml-faq.html