1 |
Wols Lists wrote: |
2 |
> On 24/12/19 18:35, Dale wrote: |
3 |
>> I'll try to see if I can get the actual error here in a bit, either a |
4 |
>> picture or the actual text. I only need one line because it is the same |
5 |
>> for them all except the name and path of the file. |
6 |
> I've just had an idea ... |
7 |
> |
8 |
> I think it was on LWN they were talking about how a directory scan on |
9 |
> linux can take absolutely ages, because as it goes through it pulls |
10 |
> everything into cache and knackers the system. (Which is why a lot of |
11 |
> programs go through the grief of using direct rather than buffered io.) |
12 |
> |
13 |
> Not sure which developer it was, but they've brought in a new mode which |
14 |
> leaves cache untouched (sort of). If it can retrieve the file from |
15 |
> cache, it does so. If it's not in cache, it pulls it in, processes it, |
16 |
> and drops it. That way the cache does not fill up with recently accessed |
17 |
> files that are never going to be touched again, and your system doesn't |
18 |
> start swapping like mad to save all this unwanted data. |
19 |
> |
20 |
> Maybe when that is enabled in plasmashell it'll fix the problem ... how |
21 |
> big is this directory that's being scanned? If it's similar or larger in |
22 |
> size to your ram that could be the problem. Even if it's rather less, if |
23 |
> other programs are using up your ram ... |
24 |
> |
25 |
> Cheers, |
26 |
> Wol |
27 |
> |
28 |
> |
29 |
|
30 |
|
31 |
I think it is indexing/caching/something that requires it to look at |
32 |
every single file in there plus all the levels below it. If so, that |
33 |
would be a huge task. Here is some info on that but I did post it a bit |
34 |
ago. It was sort of nested in one of the posts. |
35 |
|
36 |
23.5 GiB 154,090 files, 8,567 sub-folders |
37 |
|
38 |
Some NASA pics can get large at times. Some I have are quite small. |
39 |
Still, it's a LOT of files. |
40 |
|
41 |
Dale |
42 |
|
43 |
:-) :-) |