[mythtv] AutoExpire carnage due to correctly ageing automount

Andrew Meredith andrew at anvil.org
Sat Mar 18 13:53:31 UTC 2006


Hi Folks,

I posted to the mythtv-users list on the 16th March about a problem I am 
having with autoexpire. I had this problem before and simply stopped 
using the feature. This has in turn led to other problems due to the 
disk filling up :)

I have attached a simple and benign patch that will block the issue but 
would like to expand on the logic behind it.

I have two mythbackend server machines and a number of clients, all 
using FC3 or FC4 on 32 bit Intel/AMD hardware. The two servers share the 
same 100GB disk volume using autofs. I have now realised that it is 
autofs that is at the heart of the problem.

The database element RecordFilePrefix is set to "/vols/mythtv-rec" in 
both cases. In both cases "/vols" is the automount point. In both cases 
the mount is to "coliseum:/export/mythtv-rec" with the --ghost option 
set in auto.master. However, on coliseum (one of the two mythbackend 
machines) this reverts to a bind mount. On zebedee, (the other 
mythbackend machine) the mount is a standard NFS based automount.

Using the automounter provides a degree of resilience to the system such 
that if the network funks out or the server is rebooted, the slave 
server can recover without itself needing any actions taken. This 
approach works fine if no programs are set to autoexpire and has been 
doing so for well over a year.

The issue seems to kick off if the automount ages out. If there is no 
recording or playback activity on the slave backend for more than the 
time-out period, the automount does and should age out. Given that 
--ghost flag is set, the directory /vols/mythtv-rec is always present, 
irrespective of whether the mount is active or not. If the statfs test 
is run on /vols/mythtv-rec under this condition, the result returned is 
as follows:

f_type    = 391
f_bsize   = 4096
f_blocks  = 0
f_bfree   = 0
f_bavail  = 0
f_files   = 0
f_ffree   = 0
f_fsid    = 0
f_namelen = 255

However, if the statfs is run on /vols/mythtv-rec/. ie it encourages the 
automount to become active, the result is (currently)

f_type    = 26985
f_bsize   = 32768
f_blocks  = 3276480
f_bfree   = 751436
f_bavail  = 751436
f_files   = 96185600
f_ffree   = 96185462
f_fsid    = 0
f_namelen = 255

Please note that this behaviour is perfectly correct. Please also note 
that the mythbackend will then try to resolve the perceived 'disk full' 
condition by deleting the oldest member of the autoexpire queue. As the 
deletion requires access to the filesystem proper, the automount 
activates and the deletion completes.

For perspective, the result when the same tool is run on the file server is:

f_type    = 1481003842
f_bsize   = 4096
f_blocks  = 26211840
f_bfree   = 6011484
f_bavail  = 6011484
f_files   = 96185600
f_ffree   = 96185462
f_fsid    = 64768
f_namelen = 255

(Please note that the f_fsid is different, so the "delete programs" 
screen will be fooled into thinking these are two separate disks. Not 
sure how to get round this other than some kind of additional flag.)

The above is one possible scenario, but others may exist. The purpose of 
the patch is to guard against the times when the statfs call returns 
f_blocks = 0. Plainly the user would/could not create a filesystem with 
a total space of zero and even if they did, it could not store anything, 
so the autoexpire could not delete anything. Either way, if f_blocks = 0 
no further action should be taken.

I would suspect that a stale NFS mount would return a similar result, 
but have yet to prove this.

Could I please urge the developers to include this patch or equivalent 
for those of us trying to use autofs. Without it, autoexpire is like 
playing russian roulette with 5/6 chambers loaded :)

Having puzzled about the random disappearance of apparently recorded 
programs long and hard until I made the link with autoexpire, it would 
also be very useful indeed if the non verbose logging included a line of 
output naming the program deleted under autoexpire. Without this there 
is no clue as to where it went.

Thanks

Andy M

-------------- next part --------------
A non-text attachment was scrubbed...
Name: util.cpp.patch
Type: text/x-patch
Size: 413 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20060318/f294d408/attachment.bin 


More information about the mythtv-dev mailing list