perform builds on a different drive

Dominic Fandrey kamikaze at bsdforen.de
Fri Sep 10 11:54:10 EDT 2010


On 10/09/2010 16:08, Ion-Mihai Tetcu wrote:
> On Fri, 10 Sep 2010 13:17:51 +0200
> Dominic Fandrey <kamikaze at bsdforen.de> wrote:
> 
>> On 09/09/2010 23:22, Ion-Mihai Tetcu wrote:
>>> On Thu, 09 Sep 2010 22:08:50 +0200
>>> olli hauer <ohauer at gmx.de> wrote:
>>>
>>>> On 2010-09-09 16:02, Dominic Fandrey wrote:
>>>>> I intend to perform builds on a different drive similar to
>>>>> setting WRKDIRPREFIX on a regular system. I have a drive I want
>>>>> to dedicate to the task and which is mounted async, this is why
>>>>> I don't want the more permanent files stored there.
>>>>>
>>>>> On this list I found the suggestion to just make ${tb}/<BUILD>
>>>>> a symlink. However whenever I start a new build the symlink is
>>>>> removed and the directory recreated.
>>>>>
>>>>> Is there any /working/ way to perform the builds somewhere else?
>>>>>
>>>>
>>>> If you have enough RAM try the following (my actual layout)
>>>>
>>>> drive 1:
>>>>  /usr/ports
>>>>  /data/distfiles
>>>>
>>>> drive 2:
>>>>  /tinderbox
>>>>    /jails
>>>>      /8.1        => md10 (200MB swap)
>>>>      /8.1.bin    => copy of relX will be copied back to relX in
>>>> ramdisk /8.1-FreeBSD  => md11 (1400MB swap), buildspace_relX
>>>>
>>>>
>>>> With this layout and the help of the ramdisks I need in duration
>>>> ~50-60% the time for a build with my ~400 favorite ports.
>>>> I build all my ports used in prod. regularly and it is quit a
>>>> difference if the build needs 4 hours instead 8-10 hours without
>>>> ramdisks.
>>>>
>>>> On my wish list is to mark a port build done if the port is build
>>>> as decency for another port and have a higher queue id. I guess
>>>> this can bring complete build time to 2 hours instead of 4.
>>>>
>>>> PS:
>>>> In all my builds I never hit the 1400MB limit for md11.
>>>
>>> A 2GB for the build md is usually safe. But the biggest port needs
>>> about 10 times as much.
>>
>> The machine has 8GB of RAM, but my impression is that the hard disk
>> load is not very great. Shouldn't async be close to a memory disk in
>> performance?
> 
> Depending on the disks, controller, etc.
> 
> Also tindy spends much time extracting the jail tarball, especially
> when the build is on the same disk as the tarball (on QAT, for 60-70%
> this takes longer that the actually build); and in this case async
> doesn't help.

But doesn't the system cache the tarball any way? And async should
help, too. Because the file system would report the files to be
written as soon as they're committed to memory.

Also the tar balls are on a different hard disk.

-- 
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail? 


More information about the tinderbox-list mailing list