<div dir="ltr"><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small"> Hi,<br><br></div><div class="gmail_default" style="font-size:x-small"> As for the use case I am using 4 raid controllers with 12 disks on each, and only the first 75% of the drives, ( 6 TB sas ), since the sustained rate drops of after this, and scheduling to alternate fast and slow parts of the disk. The difference in performance is not the issue, it's the number of drives I have to use, 10k or 15k sas drives costs money.<br><br></div><div class="gmail_default" style="font-size:x-small"> As for api, this is what I use.<br></div><div class="gmail_default" style="font-size:x-small"> On a pristine filesystem xfs places the files allocated ( with fallocate ) from the outer to the inner tracks, which I use.<br></div><div class="gmail_default" style="font-size:x-small"> Alternatively ext4 can make a filesystem with preallocated files through a custom config to mkfs. This caused me to write a 'customizer' for an empty ext4 which is offline to create the files.<br><br></div><div class="gmail_default" style="font-size:x-small"> POSIX fallocate doesn't give any leeway, but perhaps the 'mode' part of linux fallocate could be used ? ( something like hinting, outer, fasters or similar ).<br><br></div><div class="gmail_default" style="font-size:x-small"> Preferably I would like the fs to be able to rearange the disk layout to accomodate a continous file, so a command line tool would also be fine and perhaps preferable.<br><br></div><div class="gmail_default" style="font-size:x-small"> I do see the problems involved :-D ... but when you want to store more than a couple ot thousand T rust is sooooo much cheaper.<br><br></div><div class="gmail_default" style="font-size:x-small"> / thanks , Lars.<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-03-22 11:19 GMT+01:00 Daniel Phillips <span dir="ltr"><<a href="mailto:daniel@phunq.net" target="_blank">daniel@phunq.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Lars,<span class=""><br>
<br>
On 03/21/2017 12:37 AM, Lars Segerlund wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
 Hi guys,<br>
<br>
 I am doing some apps that preallocates files at known locations on disk, continous and the order ( placement ) is important, so I thought I¨d ask if there has been any thoughts about this on tux3 ?<br>
<br>
 It¨s really a killer app for streaming, since files at the end of the disk is slower, and files on the outer part of the platter is faster.<br>
</blockquote>
<br></span>
Ah, interesting I did not realize that a factor of something less than two is so critical. And I guess you are telling us, spinning disks are not dead yet.<br>
<br>
Yes, this is something Hirofumi and I have discussed in the past. Tux3 is, in general, well suited to it. It would be required for any kind of real-time guarantee. We should have a specific plan for it, and see how the current code might be adapted for it.<span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 Preferably I¨d like to have continous files of a given size take up as much of the disk as I specify, from outer cylinders to the middle. ext4 has some support to set this up at filesystem creation time through a custom config to mkfs.<br>
<br>
So there are two issues, one is large continous file allocation, and the second is file placement.<br>
<br>
 Any thoughts ?<br>
<br>
</blockquote></span>
What API do you propose, for the user to specify these constraints?<br>
<br>
Regards,<br>
<br>
Daniel<br>
</blockquote></div><br></div>