jori.hamalainen@xxxxxxxxxxxxxxx schrieb am Montag 08 Juni 2009: > >> On 07.06.2009 01:58, Marcel Witte wrote: > >> So ext4 seems to be perfect for a video-partition, but to make it more > >> perfect, it would be nice if VDR could use the fallocate()-systemcall > >> as mentioned in the article. This would prevent fragmentation in the > >> file > > system. > > > Udo wrote: > >Sounds like a good plan, but unfortunately fallocate requires you to know > > in > > >advance how big a file will be. This is not true for VDR recordings. And > > if you fallocate with too small or too big sizes, you'll end up with > > fragmentation > > >or smaller chunks of unused space again. (All in all, this is probably > > only important for concurrent recordings anyway.) > > Well you can predict file size for certain extent. As VDR has the split > recording > option built in. That is the maximum filesize. > > - If you have 1h10min timer. > - Allocate 1st file upto split size > - Calculate average BW at the same time you are recording > - You could even store this > - If file is too small, allocate new file for remaining time with average > BW + overhead > > If you have 10min timer (or short timer which will cause filesize under > split size) > - if you store average BW what channels are having you could allocate > directly estimated size > > Naturally this is not 100% accurate, and would cause some big size > fragmentation. > > For EXT4 it would be nice: > - fallocate(4GB) > - open file for write > - close file after 3GB > - automatic fdeallocate(1GB) This was exactly the idea I had... You know the average bitrate and the timer- length, or if used the length of one "split-file". And I think 99% of all recordings will not be aborted while recording. So this would be the best way to make use of the ext4-extends. And because of the new libc/kernel you need: You can use #defines ;) also we have a development branch (1.7.x) an until this goes stable I think ext4 is a standard-file system (Fedora, Ubuntu and openSUSE will use it as default in the next versions) _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
