On Thursday 22 September 2005 13:19, Pysiak Satriani wrote:
> I might be wrong here, but bad blocks are a condition that the kernel
> should handle without barfing oops traces, so there indeed may be
> not enough sanity checks somewhere.
Perhaps...
I can do some more testing, but there are more
Gregory Maxwell wrote:
>Very interesting indeed, although it almost seems silly to tackle the
>difficult problem of making filesystems highly robust against oddball
>failure modes while our RAID subsystem falls horribly on it's face in
>the fairly common (and conceptually easy to handle) failure m
On Thu, 22 Sep 2005 18:13:23 EDT, Gregory Maxwell said:
> It would normally seem silly to use RSA for disk encryption... but
> there might be applications, although you'd still never use RSA
> directly on user controlled data. For example, RSA could be used on a
> multi user server to append mail
On 9/22/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 1) RSA is useless for this - you really need a symmetric block cipher of some
> sort. Almost all block ciphers are best used with maximum-entropy input - if
> the attacker can lop out a large part of the keyspace, a brute force attack
> be
On Thursday, 22. September 2005 22:03, Edward Shishkin wrote:
> Fred Schaettgen wrote:
> >I don't quite understand how the file plugin concept scales once we get
> > more of them. For instance if I want to have an additional attribute
> > attached to my files, which contains a checksum that is kept
Why do you need separate ones? Having only a cryptcompress file plugin
you will be able
to create files which are either only encrypted or only compressed, just
set the transform
plugins properly.
It also make sense to have compression and crypto "close" to each other,
which lets the da
On Thu, 22 Sep 2005 16:54:12 EDT, michael chang said:
> On 9/22/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > 2) Even though most modern block ciphers are designed to be fast, it's still
> > faster to apply a reasonably quick compression scheme to whomp 16K of data
> > down to 5-6K and encry
On 9/22/05, Edward Shishkin <[EMAIL PROTECTED]> wrote:
> Yes. It is impossible to implement all features in one file plugin.
> Checksuming means a low
> performance: in order to read some bytes of such file you will need
> first to read the whole file
> to check a checksum (isnt it?). So it will be
On 9/22/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 2) Even though most modern block ciphers are designed to be fast, it's still
> faster to apply a reasonably quick compression scheme to whomp 16K of data
> down to 5-6K and encrypt/decrypt 5-6k than it is to encrypt/decrypt 16K.
Two questi
On Thu, 22 Sep 2005 15:11:59 CDT, David Masover said:
> > Because sometimes it is useful to compress data before encryption since
> > compression
> > destroys vulnerable regular structure of some special files (like *.html)
>
> Although I'd imagine some algorithms are fairly resistant against th
On Fri, 23 Sep 2005 00:03:32 +0400, Edward Shishkin said:
> Checksuming means a low
> performance: in order to read some bytes of such file you will need
> first to read the whole file
> to check a checksum (isnt it?).
No. Almost all modern networking gear is *perfectly* able to do incremental
Edward Shishkin wrote:
Fred Schaettgen wrote:
On Thursday, 22. September 2005 18:41, Edward Shishkin wrote:
Grzegorz Jaśkiewicz wrote:
Or is there another reason why you packed both things into one plugin?
Because sometimes it is useful to compress data before encryption since
compr
Fred Schaettgen wrote:
On Thursday, 22. September 2005 18:41, Edward Shishkin wrote:
Grzegorz Jaśkiewicz wrote:
I think there should be file attribute that says whether it is
compressed/whatever/ or not.
Right. All the plugins responsible for compression, etc.. will be observed
On Thursday, 22. September 2005 18:41, Edward Shishkin wrote:
> Grzegorz Jaśkiewicz wrote:
> >I think there should be file attribute that says whether it is
> >compressed/whatever/ or not.
>
> Right. All the plugins responsible for compression, etc.. will be observed
> via pseudo-file interface
>
>
Grzegorz Jaśkiewicz wrote:
I think there should be file attribute that says whether it is
compressed/whatever/ or not.
Right. All the plugins responsible for compression, etc.. will be observed
via pseudo-file interface
This way, it would be possible to
compress already existing files. At l
I think there should be file attribute that says whether it is
compressed/whatever/ or not. This way, it would be possible to
compress already existing files. At least, if filesystem is so
flexible as everyone say, it would be possible.
On 9/20/05, Edward Shishkin <[EMAIL PROTECTED]> wrote:
> Guy
Title: PayPal
Dear valued PayPal® Member
It has come to our attention that your Congratulations!Papal® account information needs to be updated as part of our continuing commitment to pr
On 9/19/05, Vladimir V. Saveliev <[EMAIL PROTECTED]> wrote:
> Hello
>
> Yes, unfortunately, reiserfs does not support entry types.
> Probably it should, but there is nothing wrong to not support it:
I guess it shouldn't be hard, and this would make some code nicer. I
have run into this problem quit
Hello
Grzegorz Piotr Jaskiewicz wrote:
> still some warnings:
new verison of patch (undo previous one first), please
> CC [M] fs/reiser4/znode.o
> fs/reiser4/znode.c: In function 'znode_set_ld_key':
> fs/reiser4/znode.c:729: warning: comparisons like X<=Y<=Z do not have their
> mathematical
still some warnings:
CC [M] fs/reiser4/znode.o
fs/reiser4/znode.c: In function 'znode_set_ld_key':
fs/reiser4/znode.c:729: warning: comparisons like X<=Y<=Z do not have their
mathematical meaning
and the error.
CC [M] fs/reiser4/znode.o
fs/reiser4/znode.c: In function 'znode_set_ld_key':
fs
It seem to fix that'
cheers.
--
GJ
Binary system, you're either 1 or 0...
dead or alive ;)
Hello
Grzegorz Piotr Jaskiewicz wrote:
> Trying to get beast to compile for me, to do review and testing here, I get
> following problems with gcc 4.0.2:
>
> CC [M] fs/reiser4/debug.o
> In file included from fs/reiser4/jnode.h:12,
> from fs/reiser4/lock.h:16,
>
Trying to get beast to compile for me, to do review and testing here, I get
following problems with gcc 4.0.2:
CC [M] fs/reiser4/debug.o
In file included from fs/reiser4/jnode.h:12,
from fs/reiser4/lock.h:16,
from fs/reiser4/context.h:15,
from
Hi,
I might be wrong here, but bad blocks are a condition that the kernel
should handle without barfing oops traces, so there indeed may be
not enough sanity checks somewhere.
--
Maciej
Hello,
I experienced a Reiser4 lock-up this morning when I stopped an rdiff-backup
process.
My guess is that my hard disk has developed bad sectors. Am I correct?
To make sure I'm running badblocks now.
The kernel is 2.6.13-archck5 and here's the relevant syslog bit:
Sep 22 07:36:30 rmeijer-noc
On Thursday 22 September 2005 05:11, Markus Hiereth wrote:
> Hello,
>
> as YaST and fdisk showed different output for the partions of my
> hard-disk, I got confused and lost the correct start point for my
> partition /dev/hda5.
>
> Recreation of superblocks by reiserfsck --rebuild-sb creates a
>
26 matches
Mail list logo
