On Tue, 30 Oct 2012 20:07:57 -0700
Timothy Balcer wrote:
> In other news, the latest salvage has been running for 12 hours... I
> straced the busiest pid and it is happily verifying all the links and
> contents (open(), close(), pread() ad infinitum), so its not wedged.
> This volume has literall
On Tue, 30 Oct 2012 21:53:56 -0700
Timothy Balcer wrote:
> Huh.. per O'Reilly:
>
> "The kernel uses the SIGTERM signal to inform the target process that it
> should stop."
>
> http://linuxdevcenter.com/pub/a/linux/2006/11/30/linux-out-of-memory.html?page=2
>
> Is that out of date?
The only ti
On Mon, 29 Oct 2012 14:44:15 -0400
Jack Neely wrote:
> > You can save us a little time by providing the disassembly of
> > afs_Conn. You can get this by running
> >
> > objdump -d -r /path/to/libafs.ko > /some/file
>
> Attached.
This looks like 'objdump -d', not 'objdump -d -r', but okay.
Th
CPU and IO, it seemed. I was at an uptime of 3+ with a VM that had 2 cores,
so more CPU would have been better.
The vice partitions are slices on an underlying LVM system from its dom0.
So there are definitely other bottlenecks.
I have been considering running VMs to spread out fs operations on a
On Wed, 31 Oct 2012 10:43:02 -0700
Timothy Balcer wrote:
> I have been considering running VMs to spread out fs operations on a
> machine with many cores. On a 12 core machine, for example, I would
> make something like 4 fileservers each with 3 cores, and the
> underlying OS would be doing nothi
>
> > I have been considering running VMs to spread out fs operations on a
> > machine with many cores. On a 12 core machine, for example, I would
> > make something like 4 fileservers each with 3 cores, and the
> > underlying OS would be doing nothing except servicing those VMs. Do
> > you think t
On Sat, 27 Oct 2012 11:31:46 -0500
Andrew Deason wrote:
> It's possible for a UDP-based protocol to behave very well, and in some
> situations exceed TCP. I don't think Rx should be such a protocol, since
> I think we should be focusing on making filesystems instead of
> researching flow control.
Well, I'll try to be more clear.
Several years ago, I asked what the long-term roadmap towards
having AES and Kerberos5 was. At that time, we had the rxk5 code,
and I thought the rough consensus was that rxgk was the long-term
solution.
Since then every time I (or anyone else) asks, the response
