Carsten Koch wrote:

I have a distributed VDR system in my house with a lot of disks that are NFS mounted by VDR PCs in two rooms. In order to conserve energy, I have used hdparm to set a spin down delay after which the disks turn themselves off. When /video/.update is touched (one of the VDR PCs creates/deletes/ edits a recording, I move a recording into a folder, etc.) or when the vdr program is started, it reads all directories from all disks. Most of these directories are unchanged, so there really is no need to spin up the disk just to read a few inode entries. However, my observation is that they are always spun up. So my questions are:

1. Is there a bug in the linux kernel that makes it spin up the disk needlessly even if the data are still in the cache?

2. Is there a way to configure the kernel, so the inode entries are locked in the cache or at least get a much higher cache priority than ordinary data?

The problem is that the nfs server reads (and writes, when editing a recording on a client) large amounts of data and the metadata (which hasn't been accessed since the last /video scan) gets evicted from the cache. This usually does not happen w/ a local vdr and on the client vdrs because fadvice() makes sure that the cached video data gets freed before the system experiences any memory pressure. But fadvise() only helps locally, ie the nfs client drops the data, but the nfs server does not. I've gotten used to this; at one point, when doing the fadvise changes, i was going to implement O_DIRECT-based i/o, but decided it wasn't worth it, because of the complexity and small gains (you can't really avoid a data copy w/ the current vdr design (alignment restrictions) and the code still has to handle all the cases where O_DIRECT and/or AIO isn't available, older kernels, other filesystems etc). What you could try is:

o play with /proc/sys/vm/vfs_cache_pressure; try decreasing it. significantly. what you describe as "2)" above would be "vfs_cache_pressure=0".

Haven't tried this myself; does it help? If not the other options would probably be a bit more complex (like modifying nfsd or writing a dedicated fuse fs).

artur

Hi,

Carsten Koch wrote:

However, my observation is that they are always spun up. So my questions are:

2. Is there a way to configure the kernel, so the inode entries are locked in the cache or at least get a much higher cache priority than ordinary data?

did you had a look to noflushd?

http://noflushd.sourceforge.net/

Cheers, Andreas