[rrd-developers] rrdcached: path sanitizer

[Stanislav Sinyagin]

Kevin, you would need such lookups only once when the file path is encountered for the first time. Then it can be stored in a hash table inside rrdcached.





>________________________________
> From: kevin brintnall <kbrint at rufus.net>
>To: Kiss Gabor (Bitman) <kissg at ssg.ki.iif.hu> 
>Cc: "rrd-developers at lists.oetiker.ch" <rrd-developers at lists.oetiker.ch> 
>Sent: Wednesday, December 5, 2012 11:18 PM
>Subject: Re: [rrd-developers] rrdcached: path sanitizer
> 
>
>On Wed, Dec 5, 2012 at 8:58 AM, Kiss Gabor (Bitman) <kissg at ssg.ki.iif.hu> wrote:
>
>DESCRIPTION
>>       realpath() expands all symbolic links and resolves references  to  /./,
>>       /../  and  extra  '/' characters in the null-terminated string named by
>>       path to produce a canonicalized absolute pathname.  The resulting path-
>>       name is stored as a null-terminated string, up to a maximum of PATH_MAX
>>       bytes, in the buffer pointed to by resolved_path.  The  resulting  path
>>       will have no symbolic link, /./ or /../ components.
>>
>This is going to cause a LOT of stat() calls: O(commands * average dir depth)
>
>
>I see your point, but it's probably better to do trivial string manipulations that don't hit the filesystem.
>The whole point of rrdcached is to defer and collate I/O.
>
>
>
>If you feel strongly about it, I encourage you to benchmark it with a non-trivial number of files (500,000) and command rate (1k/sec).
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20121205/d74bd3f0/attachment-0001.htm