On Sun, Jan 15, 2012 at 11:32 PM, Dieter BSD wrote:
> I recently read somewhere that zfs needs 5 GB memory for each 1 TB of disk.
> People that run zfs obviously don't care about using lots of memory.
You read incorrectly. To run zfs with dedup needs ~ 5GB of RAM per TB,
but this depends upon fil
On Sun, 15 Jan 2012, Dieter BSD wrote:
posix_fadvise() should probably be used for large files to tell the
system not to cache the data. Its man page reminded me of the O_DIRECT
flag. Certainly if the combined size exceeds the size of main memory,
O_DIRECT would be good (even for benchmarks that
> posix_fadvise() should probably be used for large files to tell the
> system not to cache the data. Its man page reminded me of the O_DIRECT
> flag. Certainly if the combined size exceeds the size of main memory,
> O_DIRECT would be good (even for benchmarks that cmp the same files :-).
> But cmp
On Thu, 12 Jan 2012, Dieter BSD wrote:
A) Should the default vfs.read_max be increased?
Maybe, but I don't buy most claims that larger block sizes are better.
I didn't say anything about block sizes. There needs to be enough
data in memory so that the CPU doesn't run out while the disk is
se
> The hard \xc2\xa0 certainly deserves a :-(.
Agreed. Brain damaged guity-until-proven-innocent anti-spam measures
force the use of webmail for outgoing email. Which amoung other problems
inserts garbage. Sorry.
>> A) Should the default vfs.read_max be increased?
>
> Maybe, but I don't buy most c
On Thu, 5 Jan 2012, Dieter BSD wrote:
Something/somehow it's issuing smaller IOs when using mmap?
On my box, 64K reads. ??Using the '-' to avoid mmap it uses
128K.
The big difference I found was that the default mmap case isn't
using read-ahead. So it has to wait on the disk every time. ??:-(
On Wed, 4 Jan 2012, Bruce Evans wrote:
On Tue, 3 Jan 2012, Marc Olzheim wrote:
On Tue, Jan 03, 2012 at 12:21:10AM -0800, Garrett Cooper wrote:
The file is 3.0GB in size. Look at all those page faults though!
Thanks!
-Garrett
From usr.bin/cmp/c_regular.c:
#define MMAP_CHUNK (8*1024*1024
> Something/somehow it's issuing smaller IOs when using mmap?
On my box, 64K reads. Using the '-' to avoid mmap it uses
128K.
The big difference I found was that the default mmap case isn't
using read-ahead. So it has to wait on the disk every time. :-(
Using the '-' to avoid mmap it benefits
On Tue, 3 Jan 2012, Marc Olzheim wrote:
On Tue, Jan 03, 2012 at 12:21:10AM -0800, Garrett Cooper wrote:
The file is 3.0GB in size. Look at all those page faults though!
Thanks!
-Garrett
From usr.bin/cmp/c_regular.c:
#define MMAP_CHUNK (8*1024*1024)
...
for (..) {
mmap() chunk of
On 3 January 2012 00:34, Marc Olzheim wrote:
> On Tue, Jan 03, 2012 at 12:21:10AM -0800, Garrett Cooper wrote:
>> The file is 3.0GB in size. Look at all those page faults though!
>> Thanks!
>> -Garrett
>
> From usr.bin/cmp/c_regular.c:
>
> #define MMAP_CHUNK (8*1024*1024)
> ...
> for (..) {
>
On Tue, Jan 03, 2012 at 12:21:10AM -0800, Garrett Cooper wrote:
> The file is 3.0GB in size. Look at all those page faults though!
> Thanks!
> -Garrett
From usr.bin/cmp/c_regular.c:
#define MMAP_CHUNK (8*1024*1024)
...
for (..) {
mmap() chunk of size MMAP_CHUNK.
compare
On Mon, Jan 2, 2012 at 11:37 PM, Dieter BSD wrote:
> Task: cp(1) a several-GB file from one drive to another,
> then run cmp(1) to verify. Cp runs as expected, but
> cmp runs slower than expected. Neither the disks
> nor the cpu is maxed out. Local drives, no network
> involved
Task: cp(1) a several-GB file from one drive to another,
then run cmp(1) to verify. Cp runs as expected, but
cmp runs slower than expected. Neither the disks
nor the cpu is maxed out. Local drives, no network
involved. Machine is otherwise idle.
>>>
>>> 1. How are you runni
On Mon, Jan 2, 2012 at 5:29 PM, Dieter BSD wrote:
>>> Task: cp(1) a several-GB file from one drive to another,
>>> then run cmp(1) to verify. Cp runs as expected, but
>>> cmp runs slower than expected. Neither the disks
>>> nor the cpu is maxed out. Local drives, no network
>>> involved. Machi
>> Task: cp(1) a several-GB file from one drive to another,
>> then run cmp(1) to verify. Cp runs as expected, but
>> cmp runs slower than expected. Neither the disks
>> nor the cpu is maxed out. Local drives, no network
>> involved. Machine is otherwise idle.
>
> 1. How are you running cmp?
On Mon, Jan 2, 2012 at 2:19 PM, Dieter BSD wrote:
> Task: cp(1) a several-GB file from one drive to another,
> then run cmp(1) to verify. Cp runs as expected, but
> cmp runs slower than expected. Neither the disks
> nor the cpu is maxed out. Local drives, no network
> involved. Machine is othe
Task: cp(1) a several-GB file from one drive to another,
then run cmp(1) to verify. Cp runs as expected, but
cmp runs slower than expected. Neither the disks
nor the cpu is maxed out. Local drives, no network
involved. Machine is otherwise idle.
FreeBSD 8.2
amd64
4 GiB main memory
FFS soft upd
17 matches
Mail list logo
