(FWD) Re: Mixminion queue problem

[Roger Dingledine <arma@xxxxxxx>]

[Forwarding since majordomo didn't like the size of these headers. -RD]

----- Forwarded message from owner-mixminion-dev@xxxxxxxxxxxxx -----

Subject: Re: Mixminion queue problem
From: "Marco A. Calamari" <marcoc1@xxxxxxx>
Reply-To: marcoc1@xxxxxxx
To: Nick Mathewson <nickm@xxxxxxxxxxxxx>
Cc: Leonardo Giacomelli <leonardo.giacomelli@xxxxxxxxxxx>,  mixminion-dev@xxxxxxxxxxxxx, Leonardo Giacomelli <leonardo@xxxxxxxxxxxxxxxx>,  Gianni Bianchini <giannibi@xxxxxxxxxxxxxxxx>, Peter Palfrader <peter@xxxxxxxxxxxxx>
Date: Fri, 01 Apr 2005 09:24:51 +0200

On Wed, 2005-03-30 at 15:02 -0500, Nick Mathewson wrote:
> On Tue, Mar 29, 2005 at 08:57:25PM +0200, Leonardo Giacomelli wrote:
> > Nick Mathewson wrote:
> >=20
> > >>Installing a mixminion 0.0.7.1 from debian Sarge, give a perfectly
> > >> working node, except that it doesn't remove packet from
> > >> queues when packets pass from one queue to the other and get sent.
> > >=20
> > >=20
> > > How strange!  Do the packets get renamed to "rmv_......" and left lik=
e
> > > that, or do they not get renamed at all?=20
> >=20
> > Hi Nick,
> >=20
> > Yes, the packets has rmv_* prefix.. and it stays in incoming and
> > outgoing dirs. What's happen?
>=20
> Not sure yet.  When you set ShredCommand in the configuration file to
> "rm -f", does anything get better?

Replacind in ShredCommand "shred" with "rm" solved the problem; weird !

Now there is less security because packet leave more fingerprint on the
 filesystem; I'm considering to put all queues in memory.
Considering that the pbox-level-2 doesn't use virtual memory, this would
 be far better that the original situation too; this however decrease
 the node reliability, raising the probability to drop packet due to
 power failure.

.. not mentioning that this kind of system has no memory to spare...

The mixminion sw has some provision to drop old packet if the filesystem
 in which the queues are became almost full ?

Ciao.   Marco

--

"Oggi e' il domani di cui ci dovevamo preoccupare ieri."

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iQCVAwUAQkz3QolqHjrHnYhBAQKomgQAqvM4xHGsPYZ5AcLtrcj0hyFzncKbY+0/
uFhtCVHe3js9HbQgl+KYR9c9MjfuEUcwoRRugL0OWAnOJHwKBYxz4ehC0s0xND2O
T0LAnyxofLkPPighl2H41zwAGV0FlRqrlCcigUh2zWP3MR1mWBWUnikYmkb2/BLC
Des7NQeCfrA=
=zibC
-----END PGP SIGNATURE-----

----- End forwarded message -----