Two additional pieces of information.
The original limitation was more related to DEV_BSIZE calculations for
the buf/bio, which is now 64-bits and thus not applicable, though you
probably need some preemptive casts to ensure the multiplication is
done in 64-bits. There was
The limitation was ONLY due to a *minor* 32-bit integer overflow in one
or two *intermediate* calculations in the radix tree code, which I
long ago fixed in DragonFly.
Just find the changes in the DFly codebase and determine if they need
to be applied.
The swap space
.
-Matt
Matthew Dillon
dil...@backplane.com
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
: Do you know if that's changed at all with NCQ on modern SATA drives?
: I've seen people commenting that using tags recovers most, if not all,
: of the performance lost by disabling the write cache.
:...
I've never tried that combination. Theoretically the 32 tags SATA
supports would
is arguable), real RAID
hardware. And well-known vendors (fringe SSDs do not count). That
covers 90% of the market and 99% of the cases where protocol reliability
is required.
-Matt
Matthew Dillon
The core of the issue here comes down to two things:
First, a power loss to the drive will cause the drive's dirty write cache
to be lost, that data will not make it to disk. Nor do you really want
to turn of write caching on the physical drive. Well, you CAN turn it
off,
If you can swing a routed network that will definitely have the fewest
complications.
For a switched network if_bridge and ARP have to be integrated, something
I just finished doing in DragonFly, so that all member interfaces of the
bridge use *only* the bridge's MAC for all
One of the problems with resource management in general is
that it has traditionally been per-process, and due to the
multiplicative effect (e.g. max-descriptors * limit-per-descriptor),
per-process resources cannot be set such that any given user is
prevented from DDOSing the
It is actually a security issue to automatically destroy snapshots based
on whether a filesystem is full, even automatically generated snapshots.
Since one usually implements snapshots to perform a function you wish
to rely on, such as to retain backups of historical data for
:Correction -- more than likely on a consumer motherboard you *will not*
:be able to put a non-VGA card into the PCIe x16 slot. I have numerous
:Asus and Gigabyte motherboards which only accept graphics cards in their
:PCIe x16 slots; this feature is documented in user manuals. I
:don't know
The Silicon Image 3124A chipsets (the PCI-e version of the 3124. The
original 3124 was PCI-x). The 3124A's are starting to make their way
into distribution channels. This is probably the best 'cheap' solution
which offers fully concurrent multi-target NCQ operation through a
in
the buffer cache because now the VM pages are all soft-busied).
-Matt
Matthew Dillon
dil...@backplane.com
___
freebsd-stable@freebsd.org
techies :-)
These particular WDs (2TB Caviar Green's) are slow drives. 5600 rpm,
100MB/sec. But they are also very quiet in operation and seem to
be quite power efficient.
-Matt
Matthew Dillon
: mmap: 43.400u 9.439s 2:35.19 34.0%16+184k 0+0io 106994pf+0w
: read: 41.358u 23.799s 2:12.04 49.3% 16+177k 67677+0io 0pf+0w
:
:Observe, that even though read-ing is quite taxing on the kernel (high
:sys-time), the mmap-ing loses overall -- at least, on an otherwise idle
:system
What we wound up doing was splitting tvtohz() into two functions.
tvtohz_high(tv)
Returned value meets or exceeds requested time. A minimum value
of 1 is returned (really only for {0,0}.. else minimum value is 2).
tvtohz_low(tv)
Returned value might be
My experience with one of our people trying to do the same thing
w/ HAMMER... we got it working, but it is not necessarily cleaner.
I'd rather just boot from a small UFS /boot partition on 'a' (256M
or 512M), followed by swap on 'b', followed by the big-ass root
partition on
Also, if you happen to have a handheld GPS unit, it almost certainly
has a menu option to tell you the sunrise and sunset times at your
current position.
-Matt
___
freebsd-stable@freebsd.org
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Guys, please don't start a flamewar. And lhmwzy we discussed this
on the DFly lists. It's really up to them... that is, a programmer
who has an interest, inclination, and time. It isn't really fair to
try to push it.
I personally believe that the FreeBSD community as a
A couple of things to note here. Well, many things actually.
* Turning off write caching, assuming the drive even looks at the bit,
will destroy write performance for any driver which does not support
command queueing. So, for example, scsi typically has command
.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL
: -vfs.nfs.realign_test: 22141777
: +vfs.nfs.realign_test: 498351
:
: -vfs.nfsrv.realign_test: 5005908
: +vfs.nfsrv.realign_test: 0
:
: +vfs.nfsrv.commit_miss: 0
: +vfs.nfsrv.commit_blks: 0
:
: changing them did nothing - or at least with respect to nfs throughput
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
of wired ram.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman
in the filesystem that ZFS and HAMMER need to do.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
:Oliver Fromme wrote:
:
: Yet another way would be to use DragoFly's Hammer file
: system which is part of DragonFly BSD 2.0 which will be
: released in a few days. It supports remote mirroring,
: i.e. mirror source and mirror target can run on different
: machines. Of course it is still very
:Went from 10-15, and it took quite a bit longer into the backup before
:the problem cropped back up.
Try 30 or longer. See if you can make the problem go away entirely.
then fall back to 5 and see if the problem resumes at its earlier
pace.
--
It could be temperature
.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd
programs that do not supply
aligned buffers clearly don't care about performance, so the kernel
can just back the pbuf with memory and copyin/out the user data.
-Matt
Matthew Dillon
() can't be a NOP if you go by
the OpenGroup specification.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org
: 65074 python 0.06 CALL madvise(0x287c5000,0x70,_MADV_WILLNEED)
: 65074 python 0.027455 RET madvise 0
: 65074 python 0.58 CALL madvise(0x287c5000,0x1c20,_MADV_WILLNEED)
: 65074 python 0.016904 RET madvise 0
: 65074 python 0.000179 CALL
:Hi,
:
:I'm wondering if anything exists to set this.. When you create an INET
:socket
:without the 'TCP_NODELAY' flag the network layer does 'naggling' on your
:transmitted data. Sometimes with hosts that use Delayed_ACK
:(net.inet.tcp.
:delayed_ack) it creates a dead-lock where the host
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
be a reasonable bandaid, though.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org
I guess nobody mentioned the obvious thing to check: Make sure
TCP keepalive is turned on.
sysctl net.inet.tcp.always_keepalive=1
If you don't do this then dead TCP connections can build up, particularly
on busy servers, due to the other end simply disappearing.
Without
:On May 29, 2008, at 3:12 PM, Matthew Dillon wrote:
:I guess nobody mentioned the obvious thing to check: Make sure
:TCP keepalive is turned on.
:
:sysctl net.inet.tcp.always_keepalive=1
:
:
:Thanks Matt.
:
:I also thought that a keepalives were not running and sessions just
:stuck
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
:This is exactly what we're seeing, it's VERY strange. I did kill off
:Apache, and all the FIN_WAIT_1's stuck around, so the kernel is in
:fact sending these probe packets, every 60 seconds, which the client
:responds to... (most of the time).
Ach. Now that I think about it, it is
the seeks
anyway, probably.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http
fsck's memory usage is directly related to the number of inodes and
the number of directories in the filesystem. Directories are
particularly memory intensive.
I've found on my backup system that a UFS1 filesystem with 40 million
inodes is about the limit that can be
Jim's original report seemed to indicate that the filesystem paniced
on mount even after repeated fsck's.
That implies that Jim has a filesystem image that panics on mount.
Maybe Jim can make that image available and a few people can see if
downloading and mounting it
The basic answer is that HZ is almost, but not quite irrelevant.
If a process blocks another will immediately be scheduled. More
importantly, if an interrupt driven event (keyboard, tty, network,
disk, etc) wakes a process up the scheduler has the ability to force
an
the
scheduler has to make decisions based on counting quantums.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing
A friend of mine once told me that the only worthwhile RAID systems are
the ones that email you a detailed message when something goes south.
-Matt
___
freebsd-stable@freebsd.org mailing list
The vast majority of machine installations just slave their dns off
of another machine, and because of that I do not think it is particularly
odious to require some level of skill for those who actually want to set
up their own server.
To that end what I do on DragonFly is
it properly dereferencing the underlying device and properly
destroys the (now unwritable) dirty buffers.
-Matt
Matthew Dillon
[EMAIL PROTECTED
:s,/kernel,/boot/kernel/kernel, ;-)
:
:well, strange enough result for me:
:
:(kgdb) print cpu_ticks
:$1 = (cpu_tick_f *) 0x8036cef0 rdtsc
:
:Does this mean that kernel uses tsc? sysctl reports
:
:kern.timecounter.choice: TSC(-100) ACPI-fast(1000) i8254(0) dummy(-100)
it is an issue with SMP.
I'm afraid there isn't much more I can do to help, other then to make
suggestions on tests that you can run that will hopefully ring a bell
with another developer.
-Matt
Matthew Dillon
).
-Matt
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail
:IV Upd: on GENERIC/amd64 kernel I got the same errors.
:IV
:IV Do you perhaps run with TSC timecounter? (that's the only cause I've notice
:IV that can generate this message).
:
:Nope:
:
:[EMAIL PROTECTED]:~ sysctl kern.timecounter
:kern.timecounter.tick: 1
:kern.timecounter.choice: TSC(-100)
:Marc G. Fournier wrote:
: For those that remmeber the other day, I had that swzone issue, where I ran
out
: of swap space? I just about hit it again today, swap was up to 99% used
... I
: was able to get a ps listing in, and there were a whack of find processes
: running ...
:
: Now,
.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd
.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd
nearly without modification on a FreeBSD box.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
Basically maxswzone is the amount of KVM the kernel is willing to
use to store 'struct swblock' structures.
These are the little structures that are stuck onto VM objects and
specify which pages in the VM object(s) correspond to which pages
of swap, for any swapped out data
memory statistics that would be beneficial as well.
I just find it hard to imagine that any system would actually be using
that much swap, but hey! :-)
-Matt
Matthew Dillon
to
append pstat -s, vmstat -m, and vmstat -z to a file.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org
:I'm trying to probe this as well as I can, but network stacks and sockets have
:never been my strong suit ...
:
:Robert had mentioned in one of his emails about a Sockets can also exist
:without any referencing process (if the application closes, but there is still
:data draining on an open
statistics once a minute to a file then
break each report with a clear-screen sequence and cat it in a really
big xterm window.
-Matt
Matthew Dillon
[EMAIL PROTECTED
a 'vkernel' platform that linked
against libc and used the new system calls.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd-stable
nightmare to maintain.
Any failure at all could lead to a completely unrecoverable system.
-Matt
Matthew Dillon
[EMAIL PROTECTED
:How would decreasing the polling time fix this? I do not understand
:the semantics/behaviour of NTP very well.
:
:Taken from the manpage:
:
: maxpoll maxpoll
: These options specify the minimum and maximum poll intervals for
: NTP messages, in seconds to the power of two.
From 'man tuning' (I think I wrote this, a long time ago):
You should typically size your swap space to approximately 2x main mem-
ory. If you do not have a lot of RAM, though, you will generally want a
lot more swap. It is not recommended that you configure any less than
cache
rather then allowing a single run to blow it out or allowing a
static set of pages to be retained indefinitely, which is what your
tests seem to show is occuring.
-Matt
Matthew Dillon
is
using.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo
file
handles that are outside of the subdirectory tree that was exported.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd
:Actually, I can not agree here -- quite the opposite seems true. When running
:locally (no NFS involved) my compressor with the `-1' flag (fast, least
:effective compression), the program easily compresses faster, than it can
:read.
:
:The Opteron CPU is about 50% idle, *and so is the disk*
:Yes, they both do work fine, but time gives very different stats for each. In
:my experiments, the total CPU time is noticably less with mmap, but the
:elapsed time is (much) greater. Here are results from FreeBSD-6.1/amd64 --
:notice the large number of page faults, because the system does
:I thought one serious advantage to this situation for sequential read
:mmap() is to madvise(MADV_DONTNEED) so that the pages don't have to
:wait for the clock hands to reap them. On a large Solaris box I used
:to have the non-pleasure of running the VM page scan rate was high, and
:I suggested
My guess is that you are exporting the filesystem as a particular
user id that is not root (i.e. you do not have -maproot=root: in the
exports line on the server).
What is likely happening is that the NFS client is trying to push out
the pages using the root uid rather then
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
then use that user id
for all write I/O operations.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
allow the
I/O operation to run as long as some non-root user would be able to
do the I/O op.
-Matt
Matthew Dillon
[EMAIL PROTECTED
:
: [Moved from -current to -stable]
:
:צ×ÔÏÒÏË 21 ÂÅÒÅÚÅÎØ 2006 16:23, Matthew Dillon ÷É ÎÁÐÉÓÁÌÉ:
: You might be doing just writes to the mmap()'d memory, but the system
: doesn't know that.
:
:Actually, it does. The program tells it, that I don't care to read, what's
:currently
.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail
system, not
just BSD).
-Matt
Matthew Dillon
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org
:The file stops growing, but the network bandwidth remains at 20Mb/s. `Netstat
:-s' on the client, had the following to say (udp and ip only):
If the network bandwidth is still going full bore then the program is
doing something. NFS retries would not account for it. A simple
test
Polling should not produce any improvement over interrupts for EM0.
The EM0 card will aggregate 8-14+ packets per interrupt, or more.
which is only around 8000 interrupts/sec. I've got a ton of these
cards installed.
# mount_nfs -a 4 dhcp61:/home /mnt
# dd if=/mnt/x
.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL
). Then everything goes to
hell in a handbasket.
Conclusion: 1 hz would probably be a better default then 8000 hz.
-Matt
Matthew Dillon
[EMAIL PROTECTED
.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send
Polling should not produce any improvement over interrupts for EM0.
The EM0 card will aggregate 8-14+ packets per interrupt, or more.
which is only around 8000 interrupts/sec. I've got a ton of these
cards installed.
# mount_nfs -a 4 dhcp61:/home /mnt
# dd if=/mnt/x
I took a bunch of a photos at USENIX, mainly of BSD related activities.
The photos are now online at:
http://apollo.backplane.com/USENIX2004/
-Matt
Matthew Dillon
A DragonFly user noticed that usbd does not seem to get DETACH events
for UMASS devices.
I tracked this down (in the FreeBSD-5 codebase for your convenience)
to line 1382 of usb_subr.c:
/*usbd_add_dev_event(USB_EVENT_DEVICE_DETACH, dev);*/
This line was
Matthew Dillon
[EMAIL PROTECTED]
:Jan Pechanec ([EMAIL PROTECTED]) wrote:
:
:On Sat, 6 Mar 2004, Holger Kipp wrote:
:
:I experience a very repeatably but unwanted behaviour with umass/usb:
:
:System hangs/panics after detaching and attaching 8-in-1
:
:I would love to, if I could find hardware that reproduces the problem. I
:went shopping for USB thumb drives a while back and only came up with
:working ones.
:
:I have a Soyo KT400 Dragon Lite machine at home.
:
:--
:Doug White| FreeBSD: The Power to Serve
:[EMAIL
.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe
This is precisely what I did a few days ago in DragonFly. The warnings
were getting annoying.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
:
:On Sat, Aug 30, 2003 at 12:49
if
unionfs is causing a deadlock somewhere which is creating a chain of
processes stuck in 'inode' which is in turn causing vnlru to get stuck.
-Matt
Matthew Dillon
[EMAIL
:I'll try this if I can tickle the bug again.
:
:I may have just run out of freevnodes - I only have about 1-2000 free
:right now. I was just surprised because I have never seen a reference
:to tuning this sysctl.
:
:- Mike H.
The vnode subsystem is *VERY* sensitive to running out of KVM,
:On Sun, 26 Jan 2003, at 15:55 [=GMT-0800], Matthew Dillon wrote:
:
: #set hostname = 'ftp.alternic.net'
: #set remfile = 'db.root'
: #set locfile = 'db.root'
: set hostname = 'ftp.rs.internic.net'
: set remfile = domain/root.zone.gz
: set locfile = root.zone.gz
:
:Did you at some time change
it will work.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
Index: cam/scsi/scsi_da.c
===
RCS file: /home/ncvs/src/sys/cam
it.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
:
:nexus_print_all_resources(c0e62280,c0e4a680,c0e62280,c0e62280,0) at
:nexus_print_all_resources+0x14
:...
Index: nexus.c
Oh, also, just a general note to people. These bug reports are great,
it tells us that something went wrong, but it would be nice if they
were a little more complete :-) For example, it wasn't until the 20th
posting in this and the similar other kernel panic thread on -hackers
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
(adding the general list back in!)
:
:On Thu, 5 Sep 2002, Matthew Dillon wrote:
:
: Whew! These are big! :-). I've got jupiter's files downloaded, now
: it's working on venus.
:
:Ya, both are 4gig servers :) That was why netdump was so critical, cause
:they are also both
.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Matthew Dillon
[EMAIL PROTECTED]
...
:11:50:14.485255 freebsd.nfs solaris.0: reply ok 1460 (DF)
:11:50:14.485378 freebsd.nfs solaris.0: reply ok 1460 (DF)
:11:50:14.485510 freebsd.nfs solaris.0: reply ok 1460 (DF)
(HERE)
:11:50:14.580651 solaris.1022
1 - 100 of 150 matches
Mail list logo
