3 ms·

I am all for having the mlocate program, but imposing a chron schedule on a server that causes heavy IO is stupid. Interestingly they have understood and disab

by cft 10y ago

I am all for having the mlocate program, but imposing a chron schedule on a server that causes heavy IO is stupid. Interestingly they have understood and disabled the mlocate chron in the server versions since at least 14.01. Have you administered a server with say 10m small files? It runs with negligible IO under normal traffic since recently accessed files are cached in memory, but running locate will kill its disks (sometimes physically). There were other features in Unix for "decades", such as Bash Shellshock bug for example.

acdha 10y ago
Having a cron job which makes something useful out of the box is not stupid. It's useful for most people and any sysadmin who needs to customize what is indexed can easily do so if there's a path they want to exclude which isn't already in the default list. 10M files isn't a huge amount by post-90s standards and talking about disk access destroying hardware is pure hyperbole. If you have disks failing that frequently something is wrong with your server room, cooling, etc. A daily cron task is not a make or break problem there: I mean, 15 years ago I had that many small files backing a departmental email setup (maildir, so one file per message) — if you think locate is a problem, consider the I/O characteristics of hundreds of IMAP sessions and remember that RAM was a lot more expensive back then and many individual users had mailboxes larger than the aggregate total server memory). Drives failed, yes, but usually after years of heavy service.
- JdeBP 10y ago
  You are erroneously conflating disc failures with database failures, which is what was actually written.
  - acdha 10y ago
    It's generally considered poor form around here to accuse people of not reading correctly with no further discussion. Perhaps you could enlighten us by explaining how the quote I was responding to, “will kill its disks (sometimes physically)”, is so clearly about databases rather than disks?

by cft 10y ago

acdha 10y ago

Having a cron job which makes something useful out of the box is not stupid. It's useful for most people and any sysadmin who needs to customize what is indexed can easily do so if there's a path they want to exclude which isn't already in the default list. 10M files isn't a huge amount by post-90s standards and talking about disk access destroying hardware is pure hyperbole. If you have disks failing that frequently something is wrong with your server room, cooling, etc. A daily cron task is not a make or break problem there: I mean, 15 years ago I had that many small files backing a departmental email setup (maildir, so one file per message) — if you think locate is a problem, consider the I/O characteristics of hundreds of IMAP sessions and remember that RAM was a lot more expensive back then and many individual users had mailboxes larger than the aggregate total server memory). Drives failed, yes, but usually after years of heavy service.

JdeBP 10y ago
You are erroneously conflating disc failures with database failures, which is what was actually written.
- acdha 10y ago
  It's generally considered poor form around here to accuse people of not reading correctly with no further discussion. Perhaps you could enlighten us by explaining how the quote I was responding to, “will kill its disks (sometimes physically)”, is so clearly about databases rather than disks?