[vdr] Re: max. latency time to large, bad response from vdr

[Carsten Koch <Carsten.Koch@icem.de>]

Emil Naepflein wrote:
...
> I can supply you code which improves the situation considerable by
> avoiding the external FINDCMD and limiting the search depth until a
> "*.rec" or "*.del" directory is found. This avoids all the unnecessary
> stats for the files in those directories. 
Good idea.

> The next step for me would be
> to keep the read info until there is any change by adding or deleting
> any recordings and change of modification time of the primary video
> directory. 
You have to be careful here.
The modification time does not propagate up the directory tree:

cko/hp> cd /tmp/
/tmp> mkdir d1
/tmp> cd d1
/tmp/d1> mkdir d2
/tmp/d1> cd d2
d1/d2> mkdir d3
d1/d2> cd d3
d2/d3> touch a
d2/d3> ls -al /tmp/d1
total 4
drwxr-xr-x    3 cko      users          15 2003-07-23 16:40 .
drwxrwxrwt   12 root     root         4096 2003-07-23 16:40 ..
drwxr-xr-x    3 cko      users          15 2003-07-23 16:40 d2
d2/d3> date
Wed Jul 23 16:41:19 CEST 2003
d2/d3> cd ..
d1/d2> rm -rf d3
d1/d2> ls -al /tmp/d1
total 4
drwxr-xr-x    3 cko      users          15 2003-07-23 16:40 .
drwxrwxrwt   12 root     root         4096 2003-07-23 16:40 ..
drwxr-xr-x    2 cko      users           6 2003-07-23 16:41 d2

So I guess it is not sufficient to monitor the modification time of
the primary video directory.


> It is really bad that Linux behaves that strange when reading/writing
> large amounts of data. It should keep the file metadata incore instead
> of pushing it out.
Yes.
That is utterly brain-dead.
The meta data is so small, it could be kept in memory most of the time
without significant loss of buffer space.
In many situations, the buffered data will never be used again and all
they do is push more important data out.
Maybe we should post a suggestion onto the XFS mailing list?

Carsten.



--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.