On Sun, Oct 31, 2010 at 9:38 AM, Warren Block wrote:
> About a month ago, ccache began to pause in buildworld. The build doesn't
> halt or quit, it stays running but not doing anything:
>
> /usr/local/libexec/ccache/world-cc -fpic -DPIC -O2 -pipe -march=prescott
> -I/usr/src/lib/libc/include -I/u
On Sun, 31 Oct 2010, Garrett Cooper wrote:
On Sun, Oct 31, 2010 at 9:38 AM, Warren Block wrote:
About a month ago, ccache began to pause in buildworld. The build doesn't
halt or quit, it stays running but not doing anything:
/usr/local/libexec/ccache/world-cc -fpic -DPIC -O2 -pipe -march=pre
On Sun, Oct 31, 2010 at 5:21 PM, Warren Block wrote:
> On Sun, 31 Oct 2010, Garrett Cooper wrote:
>
>> On Sun, Oct 31, 2010 at 9:38 AM, Warren Block wrote:
>>>
>>> About a month ago, ccache began to pause in buildworld. The build
>>> doesn't
>>> halt or quit, it stays running but not doing anyth
On Sun, Oct 31, 2010 at 8:02 PM, Garrett Cooper wrote:
>Question is, is it ccache's fault, or something else's?
>FWIW, it would be really nice to see what the 4th file descriptor
> actually maps to, and what command is being run at the time, as well
> as what other commands are being run.
:cronfy wrote:
:
:> And also, maybe there are other ways to create incremental backups
:> instead of using rsync/hardlinks?
:
:Yes. Use dump(8) -- that's what it's for. It reads the inodes,
:directories, and files directly from the disk device, thereby
:eliminating stat() overhead entirely.
:
:
About a month ago, ccache began to pause in buildworld. The build
doesn't halt or quit, it stays running but not doing anything:
/usr/local/libexec/ccache/world-cc -fpic -DPIC -O2 -pipe -march=prescott
-I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include
-I/usr/src/lib/libc/i386-DNLS
[missing attribution restored]
Matthew Dillon wrote:
> per...@pluto.rain.com wrote:
> :cronfy wrote:
> :
> :> And also, maybe there are other ways to create incremental backups
> :> instead of using rsync/hardlinks?
> :
> :Yes. Use dump(8) -- that's what it's for. It reads the inodes,
> :direct
:> and the output produced by dump is not live-accessible whereas a
:> snapshot / live filesystem copy is. That makes the dump fairly
:> worthless for anything other than catastrophic recovery.
:
:Ever heard of "restore -i"?
Have you ever tried to restore a single file from a 2 Terrabyte dump
8 matches
Mail list logo