KDB and KDB_TRACE are now included into GENERIC kernels on stable/8 branch.
This should not break anything for you. But if you include GENERIC into your
custom kernel config and you already have the above options there, then you will
get warnings about duplicate options. You can simply remove
What speed do you expect? IIRC from my tests, I was able to saturate
1Gbit link with initial synchronization. Also note, that hast
synchronize only differences, and not the entire thing after crash or
power failure.
I should probably have put some numbers in the original email,
sorry! I am
If you are 50ms RTT from the remote system, the default buffer size will
limit you to about 21 Mbps. Formula is Window-size(in bits/sec)/RTT(in
sec.) The result is the absolute maximum possible bandwidth in
bits/sec. Of course, you can replace window size with the bytes/sec and
the result
TB --- 2010-10-25 08:30:07 - tinderbox 2.6 running on freebsd-stable.sentex.ca
TB --- 2010-10-25 08:30:07 - starting RELENG_7 tinderbox run for i386/i386
TB --- 2010-10-25 08:30:07 - cleaning the object tree
TB --- 2010-10-25 08:30:31 - cvsupping the source tree
TB --- 2010-10-25 08:30:31 -
You could change the values and recompile hastd :-). It would be interesting
to know about the results of your experiment (if you do).
I changed the buffer sizes to the same as I was using for ggate, but the speed
is still the same - 44meg/second (about half of what the link can do)
On Mon, 25 Oct 2010 11:55:34 +0100 Pete French wrote:
You could change the values and recompile hastd :-). It would be interesting
to know about the results of your experiment (if you do).
PF I changed the buffer sizes to the same as I was using for ggate, but the
speed
PF is still the
Warren Block wrote:
I've had mixed success with cdrecord (sysutils/cdrtools-devel) over the
years. Although growisofs is reputed to be less correct, I can't recall
it ever having a problem.
Isn't cdrtools dependency of growisofs?
regards,
- Jakub Lach
--
View this message in
On Mon, 25 Oct 2010, Jakub Lach wrote:
Warren Block wrote:
I've had mixed success with cdrecord (sysutils/cdrtools-devel) over the
years. Although growisofs is reputed to be less correct, I can't recall
it ever having a problem.
Isn't cdrtools dependency of growisofs?
Yes, although maybe
Hello,
am I complete stupid or is there a serious problem with 8.1-RELEASE:
I can write files which I have no write access to, if I have write
access to the directory of the file.
How to reproduce (tested with UFS2):
mkdir /tmp/testdir
touch /tmp/testdir/testfile
chown -R nobody:intern
schrieb Harald Schmalzbauer am 25.10.2010 23:20 (localtime):
Hello,
am I complete stupid or is there a serious problem with 8.1-RELEASE:
I can write files which I have no write access to, if I have write
access to the directory of the file.
...
This means file permission mode is irrelevant
On Oct 25, 2010, at 2:20 PM, Harald Schmalzbauer wrote:
chmod g+w testdir/ (as superuser, exit again)
ls -ld testdir
drwxrwx--x 2 nobody intern 512 25 Okt 23:03 testdir
ls -l testdir
total 0
-rw-r- 1 nobody intern 0 25 Okt 23:03 testfile
- Now editing with vi (as user
After a csup, building the GENERIC kernel on amd64 fails with:
make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP=cc -E
CC=cc xargs mkdep -a -f .newdep -O2 -frename-registers -pipe
-fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes
On 2010/10/26 at 06:37, Chip Camden sterl...@camdensoftware.com wrote:
After a csup, building the GENERIC kernel on amd64 fails with:
Exactly the same here, but with a custom kernel on 8-STABLE amd64.
make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP=cc -E
CC=cc xargs mkdep -a -f
On Mon, Oct 25, 2010 at 03:37:44PM -0700, Chip Camden wrote:
After a csup, building the GENERIC kernel on amd64 fails with:
make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP=cc -E
CC=cc xargs mkdep -a -f .newdep -O2 -frename-registers -pipe
-fno-strict-aliasing -std=c99 -g -Wall
14 matches
Mail list logo
