id summary reporter owner description type status priority milestone component version severity resolution keywords cc mlocked 2242 Recordings not being deleted fast enough Martin Ebourne Isaac Richards "I noticed my recordings partition was nearly full so deleted several shows to make some space. It appears the new gradual file truncation code is too gradual because it's not deleting them fast enough. I have one DVB channel currently recording. Originally the free space looked like this: 150G 144G 6.1G 96% /mnt/recording So I deleted several shows as per this (output from lsof): {{{ mythbacke 25571 mythtv 23w REG 253,2 5399902004 67259165 /srv/media/recording/1030_20060823192900.mpg (deleted) mythbacke 25571 mythtv 54w REG 253,2 1544553292 67109020 /srv/media/recording/1012_20060526205900.mpg (deleted) mythbacke 25571 mythtv 55w REG 253,2 1786772492 67109041 /srv/media/recording/1012_20060616205900.mpg (deleted) mythbacke 25571 mythtv 56w REG 253,2 1793806700 67110461 /srv/media/recording/1012_20060707205900.mpg (deleted) mythbacke 25571 mythtv 57w REG 253,2 21568151552 67259106 /srv/media/recording/1001_20060819182900.mpg (deleted) }}} Over half an hour later and the free space looks like this: 150G 146G 4.3G 98% /mnt/recording Looking at the r10235 commit I can see that it is supposed to delete faster than the calculated recording rate but this is clearly not working. My disk is gradually filling up and soon it will die. Unfortunately I have no useful log since I'm not running the backend with -v file although I will for next time (this happened once before but I couldn't log in and investigate). If I stop and restart with the verbose of course the files will delete immediately. The machine is backend only, there's plenty of free cpu and the filesystem is xfs so there's no reason for it not to keep up." patch closed minor unknown mythtv head medium fixed 0