Pre-allocating disk space? (2 Viewers)

[grubi]

gxtracker:

Then maybe it is a good idea to change the following article on Wikipedia about fragmentation: Fragmentierung (Dateisystem) Wikipedia
It mentions preallocation as method to avoid fragmentation.

And you should avoid using Azureus. Other clients have at least the option to use preallocation.

>>The windows copy command is optimized to deal with smaller files - hardly a comparison when
>>considering the size differential of MPEG2 video data.

I really don't know what exactly the copy comand is beeing optimized for. The only thing I know is that it uses preallocation to prevent fragmentation on the target file. Total Commander by the way is doing the same thing on it's internal copy comand.

Sure there are many points of view about preallocation, however IMHO it is an often used, simple method to effectively avoiad fragmentation. How otherwise should the OS know that the file you are writing to will get very large. I will repeat myself but IMHO this is not fixing an os layer bug but good programming style as you give the os more information to handle your intended operation the most effective way.

just my 2 cents.
grubi.

 

[tourettes]

hmm... one possible issue did come into my mind TsReader might not like when the actual file end is far beound the end of actual data. But I have some dim memory that some Windows API allows to give some hints to the system / file system that how big file we are going to write.

But... doesnt the timeshifting files already have the pre configured size? Is the .tsbuffer file containing some hints for TsReader? If yes then we could use similar for the recordings until the recording is complete and the file can be trimmed at the end to match the actual data length. After the recording is done and file is trimmed we could delete the corresponding .tsbuffer file.

 

[grubi]

hmm... one possible issue did come into my mind TsReader might not like when the actual file end is far beound the end of actual data. But I have some dim memory that some Windows API allows to give some hints to the system / file system that how big file we are going to write.

But... doesnt the timeshifting files already have the pre configured size? Is the .tsbuffer file containing some hints for TsReader? If yes then we could use similar for the recordings until the recording is complete and the file can be trimmed at the end to match the actual data length. After the recording is done and file is trimmed we could delete the corresponding .tsbuffer file.

For the tsbuffer there are two files created, the ts and the tsbuffer file. I would gues that the second, small one contains the navigation info. On creation the file has 256 MB and is truncated as soon as you stop live tv.

grubi.

 

[and-81]

The same thing would be done for recordings, but I guess during playback of a file that is still recording there could be some issues if you hit the end of the valid data ...

There is probably a way around that, so I'd press on and cross that bridge when we get to it.

Cheers,

 

[urev]

Hi,
any news on this topic? My htpc suffers from fragmentation. With 5 tuners I get recordings with 200 and even 1000 fragments a few days after I defragmented my HDD (with JKdefrag). I think it is not very clever to run a defrag program every day if mediaportal could decrease the fragmentation itself. By the way I increased the cluster size of my recording partition already to the windows maximum (64kB if I remember correctly? Any other ways to minimize fragmentation?

bye, urev

 

[Eeyore]

I'm digging this old thread up again for discussion.

I have the same issue with 3 tuners creating 10's of thounds of fragments per night. Is there any opportunity to get something like file size pre-allocation added to MePo 2?

If we make it a user definable setting, then everyone can tweek it (or turn it off) depending on their requirements. Personally, I believe a 256MB preallocation would be great.

The attachment is my TV Recording parition after 1 night of 4 recordings. Yellow is fragmented. Blue space is contiguous, but these are old shows that were already defragmented.

 

[essdiem]

How about creating a different partition for each of your TV cards? One card saves recordings to drive 1, the other to drive 2? Also create a separate partition for your timeshifting (if you don't use a RAMdisk).

Mine is set up this way and seems to do the job.