On 3/1/2013 10:06 PM, Mike Tancsa wrote:
> On 3/1/2013 3:34 PM, Dag-Erling Smørgrav wrote:
>> Mike Tancsa writes:
>>> Dag-Erling Smørgrav writes:
Are you sure this was due to the OpenSSH update, and not the OpenSSL
update a few days ago? Can you try to roll back to r247484?
>>> I didnt
On Fri, 01 Mar 2013 21:34:39 +0100, Daniel Eischen
wrote:
On Fri, 1 Mar 2013, Ben Morrow wrote:
Quoth Daniel Eischen :
Yes, we still use a couple of DLT autoloaders and have nightly
incrementals and weekly fulls. This is the problem I have with
converting to ZFS. Our typical recovery is
Hi!
Im trying to limit memory usage for jails with the rctl API. But I don't really
get it.
I have compiled the kernel with the right options and rctl show me stuff like:
jail:jail22:memoryuse:deny=268435456
jail:jail22:swapuse:deny=268435456
jail:jail20:memoryuse:deny=268435456
jail:jail20:swap
On Fri, 01 Mar 2013 18:55:22 +0100, Volodymyr Kostyrko
wrote:
01.03.2013 16:24, Karl Denninger:
Dabbling with ZFS now, and giving some thought to how to handle backup
strategies.
ZFS' snapshot capabilities have forced me to re-think the way that I've
handled this. Previously near-line (and
Mike Tancsa writes:
> This PR looks to be related
>
> http://lists.freebsd.org/pipermail/freebsd-bugs/2012-September/050139.html
That suggests a bug in the aesni driver...
Can you ktrace sshd in both cases? My guess is the difference is that
the new version uses hw offloading while the old vers
On 3/2/2013 10:33 AM, Dag-Erling Smørgrav wrote:
> Mike Tancsa writes:
>> This PR looks to be related
>>
>> http://lists.freebsd.org/pipermail/freebsd-bugs/2012-September/050139.html
>
> That suggests a bug in the aesni driver...
OK, but the above uses the glxsb driver, not the aesni driver. Als
Mike Tancsa writes:
> The pcaps and basic wireshark output at
>
> http://tancsa.com/openssh/
This is 6.1 with aesni vs 6.1 without aesni; what I wanted was 6.1 vs
5.8, both with aesni loaded.
Could you also ktrace the server in both cases?
An easy workaround is to change the list of ciphers the
On 3/2/2013 11:02 AM, Dag-Erling Smørgrav wrote:
> Mike Tancsa writes:
>> The pcaps and basic wireshark output at
>>
>> http://tancsa.com/openssh/
>
> This is 6.1 with aesni vs 6.1 without aesni; what I wanted was 6.1 vs
> 5.8, both with aesni loaded.
Ahh, ok. I will do it later this aft.
>
>
Dag-Erling Smørgrav writes:
> This is 6.1 with aesni vs 6.1 without aesni; what I wanted was 6.1 vs
> 5.8, both with aesni loaded.
On second thought, I don't need more pcaps.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-stable@freebsd.org mail
Wiadomość napisana przez Peter Ankerstål w dniu 2 mar 2013, o godz. 16:21:
> Hi!
>
> Im trying to limit memory usage for jails with the rctl API. But I don't
> really get it.
>
> I have compiled the kernel with the right options and rctl show me stuff like:
> jail:jail22:memoryuse:deny=268435456
On Mar 2, 2013, at 5:15 PM, Edward Tomasz Napierała wrote:
>>
>
> [..]
>
> Could you please do "jls jid name" and verify that a jail named "jail20" is
> actually
> running?
>
> --
> If you cut off my head, what would I say? Me and my head, or me and my body?
>
>
Oh!
My bad, I thought it
On Sat, 2013-03-02 at 17:02 +0100, Dag-Erling Smørgrav wrote:
> Mike Tancsa writes:
> > The pcaps and basic wireshark output at
> >
> > http://tancsa.com/openssh/
>
> This is 6.1 with aesni vs 6.1 without aesni; what I wanted was 6.1 vs
> 5.8, both with aesni loaded.
>
> Could you also ktrace th
Wiadomość napisana przez Peter Ankerstål w dniu 2 mar 2013, o godz. 17:18:
> On Mar 2, 2013, at 5:15 PM, Edward Tomasz Napierała wrote:
>>>
>>
>> [..]
>>
>> Could you please do "jls jid name" and verify that a jail named "jail20" is
>> actually
>> running?
>>
>> --
>> If you cut off my head,
On Mar 1, 2013, at 21:14, Ben Morrow wrote:
> But since ZFS doesn't support POSIX.1e ACLs that's not terribly
> useful... I don't believe bsdtar/libarchive supports NFSv4 ACLs yet.
Ah yes, just noticed that. Thought it did.
https://github.com/libarchive/libarchive/wiki/TarNFS4ACLs
_
On 2013-Mar-01 08:24:53 -0600, Karl Denninger wrote:
>If I then restore the base and snapshot, I get back to where I was when
>the latest snapshot was taken. I don't need to keep the incremental
>snapshot for longer than it takes to zfs send it, so I can do:
>
>zfs snapshot pool/some-filesystem@u
On 3/2/2013 4:14 PM, Peter Jeremy wrote:
> On 2013-Mar-01 08:24:53 -0600, Karl Denninger wrote:
>> If I then restore the base and snapshot, I get back to where I was when
>> the latest snapshot was taken. I don't need to keep the incremental
>> snapshot for longer than it takes to zfs send it, s
- Original Message -
From: "Karl Denninger"
Reality however is that the on-disk format of most database files is
EXTREMELY compressible (often WELL better than 2:1), so I sacrifice
there. I think the better option is to stuff a user parameter into the
filesystem attribute table (which a
>The "recommended" approach is to do zfs send | zfs recv and store a
>replica of your pool (with whatever level of RAID that meets your
>needs). This way, you immediately detect an error in the send stream
>and can repeat the send. You then use scrub to verify (and recover)
>the replica.
I do zf
Quoth Ben Morrow:
> I don't know what medium you're backing up to (does anyone use tape any
> more?) but when backing up to disk I much prefer to keep the backup in
> the form of a filesystem rather than as 'zfs send' streams. One reason
> for this is that I believe that new versions of the ZFS cod
Quoth Karl Denninger :
> Quoth Ben Morrow:
> > I don't know what medium you're backing up to (does anyone use tape any
> > more?) but when backing up to disk I much prefer to keep the backup in
> > the form of a filesystem rather than as 'zfs send' streams. One reason
> > for this is that I believe
On 3/2/2013 10:23 PM, Ben Morrow wrote:
> Quoth Karl Denninger :
>> Quoth Ben Morrow:
>>> I don't know what medium you're backing up to (does anyone use tape any
>>> more?) but when backing up to disk I much prefer to keep the backup in
>>> the form of a filesystem rather than as 'zfs send' stream
Karl Denninger (karl) writes:
>
> I think I'm going to play with this and see what I think of it. One
> thing that is very attractive to this design is to have the receiving
> side be a mirror, then to rotate to the vault copy run a scrub (to
> insure that both members are consistent at a checksu
Quoth Phil Regnauld :
>
> > The only risk that makes me uncomfortable doing this is that the pool is
> > always active when the system is running. With UFS backup disks it's
> > not -- except when being actually written to they're unmounted, and this
> > materially decreases the risk of an insane
23 matches
Mail list logo
