On 8/29/06, PFC [EMAIL PROTECTED] wrote:
Anyone has a bench for lzf ?
This is on a opteron 1.8GHz box. Everything tested hot cache.
Testing on a fairly repetative but real test case (an SQL dump of one
of the Wikipedia tables):
-rw-rw-r-- 1 gmaxwell gmaxwell 426162134 Jul 20 06:54
On 8/29/06, David Masover [EMAIL PROTECTED] wrote:
[snip]
Conversely, compression does NOT make sense if:
- You spend a lot of time with the CPU busy and the disk idle.
- You have more than enough disk space.
- Disk space is cheaper than buying enough CPU to handle compression.
-
On 8/15/06, Edward Shishkin [EMAIL PROTECTED] wrote:
checksumming is _not_ much more easy then ecc-ing from implementation
standpoint, however it would be nice, if some part of errors will get
fixed without massive surgery performed by fsck
We need checksumming even with eccing... ECCing on
On 8/15/06, Tom Reinhart [EMAIL PROTECTED] wrote:
Of course, not everyone uses RAID. ECC would benefit some people in some
cases... no argument there.
We can use RAID mechanisms (RS erasure code) on a single disk. You
could technically call it ECC, but if you do so you will confuse
people.
On 8/3/06, Matthias Andree [EMAIL PROTECTED] wrote:
Berkeley DB can, since version 4.1 (IIRC), write checksums (newer
versions document this as SHA1) on its database pages, to detect
corruptions and writes that were supposed to be atomic but failed
(because you cannot write 4K or 16K atomically
On 8/1/06, David Masover [EMAIL PROTECTED] wrote:
Yikes. Undetected.
Wait, what? Disks, at least, would be protected by RAID. Are you
telling me RAID won't detect such an error?
Unless the disk ECC catches it raid won't know anything is wrong.
This is why ZFS offers block checksums... it
On 7/31/06, Alan Cox [EMAIL PROTECTED] wrote:
Its well accepted that reiserfs3 has some robustness problems in the
face of physical media errors. The structure of the file system and the
tree basis make it very hard to avoid such problems. XFS appears to have
managed to achieve both robustness
On 5/23/06, Tom Vier [EMAIL PROTECTED] wrote:
[snip]
What i'm doing is rsyncing from a slower drive (on 1394) to the raid1 dev.
When using r4 (xfs behaves similarly), after several seconds, reading from
the source and writing to the destination stops for 3 or 4 seconds, then
brief burst of
On 4/27/06, Sander [EMAIL PROTECTED] wrote:
I have a simple solid state disk to play with here.
See http://nerv.eu.org/iram/
Interesting review, thanks.
To get better reliability you could raid1 them.
I guess this is a 'must' anyway when used in servers (just like with
harddisks).
Have
On 4/27/06, Toby Thain [EMAIL PROTECTED] wrote:
Sure ECC would be nice, but how does this differ from disk? Silent
failures are certainly possible.
The fact that error detection and propagation doesn't really happen
in modern disk subsystems is why systems like Sun's ZFS are coming
into
How does this http://marc.theaimsgroup.com/?t=11448928423 impact
reiser4's atomic writes?
On 1/9/06, Giovanni A. Orlando [EMAIL PROTECTED] wrote:
Hans,
Can you tell me please the status of Reiser4 in the Kernel?
Here is the thread you were supposted to read... (I think):
http://marc.theaimsgroup.com/?l=linux-kernelm=113650213621940w=2
Looks like ZFS is no longer vaporware.
http://www.opensolaris.org/os/community/zfs/docs/
Any commentary from the Reiserfs team?
A (supposedly) production ready FS that provides the transactions
(using a similar/same tree ripple technique as reiser4), compression,
and snapshotting, that we
Any thought to making a file plugin that creates copy on write files?
The operation would be something like a hardlink which is invisible to
the user and broken as soon as either file is modified.
Files could be COWed by a flag on the cp command (or really, perhaps
that should be the default
On 10/25/05, Hans Reiser [EMAIL PROTECTED] wrote:
This would not be (at least in theory) useful for RAID devices, but for
a user with a single disk drive, it might be useful to have a plugin
that creates two (or N) copies, and tries to allocate the two copies at
opposite ends of the disk.
On 10/25/05, Sander [EMAIL PROTECTED] wrote:
That will kill performance badly. First of all the two read/writes
needed, and second because you have to seek from one end to the disk to
the other every time you read/write something.
Kill it worse for writes than a filesytem without wandering
On 10/25/05, Ingo Bormuth [EMAIL PROTECTED] wrote:
I agree, real backups are the major weappon against classical data loss due
to hardware failure.
Other quite anoying and common causes for data loss are accidentally deleted,
overwritten or modified files. A _simple_ versioning plugin would be
On 10/17/05, Hans Reiser [EMAIL PROTECTED] wrote:
In fact, if you have enough RAM, you won't ever touch the
disk -- deleting a file before it's committed means it never touches disk.
It is not as spindown-friendly as laptop_mode, which notices when the
drive has to spin up anyway (maybe
On 10/10/05, Christian Iversen [EMAIL PROTECTED] wrote:
I suggest you run Spinrite (grc.com, ~$50 IIRC) on the bad disk from a
floppy or CD-ROM in DOS (the program makes images for you in Windows,
if you have a working partition, or you can get images from the site
IIRC once you've bought
On 10/1/05, Artur Makówka [EMAIL PROTECTED] wrote:
but is there some official statment about using 2.6.x reiser4 patches with
2.6.x.x kernels? i mean, does patch called reiser 4 2.6.13 patch is also
intended to work with 2.6.13.2 for example or only with 2.6.13 ?
You aren't likely to get one.
On 9/29/05, Artur Makówka [EMAIL PROTECTED] wrote:
Will it work also with 2.6.13.2 kernel ? or is it only for 2.6.13 ( or
2.6.13.1 )
i couldnt find any information about this on page, and i want to be sure...
I used it fine with 2.6.13.2... but my wireless card isn't supported
there. (it's
On 9/29/05, Hans Reiser [EMAIL PROTECTED] wrote:
It works on non-amd64, will fix amd64 tomorrow I hope.
No, it fails on FC4/x86 here to complie as well, with the same failure mode.
On 9/23/05, David Greaves [EMAIL PROTECTED] wrote:
who's not keeping up with the linux-raid list then ;)
David
PS I'm sure assistance would be appreciated in testing and reviewing
this few day old feature - or indeed the newer 'add a new disk to the
array' feature.
After posting that I
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:
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
becomes
On 9/20/05, Clay Barnes [EMAIL PROTECTED] wrote:
Forgive me if this has been answered recently, but I haven't gotten my
last two dozen e-mails for today yet.
Regarding the compression plugin, what sort of compression can one
expect from it?
[snip]
Just a general, no reiser4 specifc answer
On 9/20/05, David Masover [EMAIL PROTECTED] wrote:
Probably lzo, which is already used for other things like network
connections (ssh, openvpn, and so on). The nice thing about lzo is that
it's fast, faster than gzip or bzip2, and gets decent compression -- not
great, but decent. I don't
On 9/20/05, Theodore Ts'o [EMAIL PROTECTED] wrote:
The script could be improved by select random locations to damage the
filesystem, instead of hard-coding the seek=7 value. Seek=7 is good
for testing ext2/ext3 filesystems, but it may not be ideal for other
filesystems.
What would be
So the post about file system failure modes made me think of something
interesting...
We'd discussed in the past that it would be interesting to store
cryptographic hashes of files as metadata for facilitating
applications which require hashes as well as data integrity. Of
course, the challenge
On 9/20/05, Hans Reiser [EMAIL PROTECTED] wrote:
I am not a big fan of formal committees, but would be happy to take
part in any effort to standardize, code and test the result...
The committee could simply exchange a set of emails, and agree on
things. I doubt it needs to get all
On 9/16/05, Tomasz Chmielewski [EMAIL PROTECTED] wrote:
yeah, but it is to be used by the end-user.
the archive will be still filled with spam.
not everyone who wants to know about reiser subscribes to the list; most
of the people would just use the archives.
I actually subbed to the list
On 9/6/05, Hans Reiser [EMAIL PROTECTED] wrote:
Guys, I am sorry, but I just don't think this issue is a priority
compared to other issues. Sorry, too much else going on, honestly.
I'd say so:
Per Andrew Morton.
reiser4 merge status:
Stuck. Last time we discussed this I asked the
On 9/2/05, Łukasz Mierzwa [EMAIL PROTECTED] wrote:
Dnia Fri, 02 Sep 2005 09:19:55 +0200, Hans Reiser [EMAIL PROTECTED] napisał:
It could probably be a lot less than 5%, 2% is more than enough I would
guess, but we also need to reserve space to get good performance.
Maybe You can make it an
On 9/1/05, Pysiak Satriani [EMAIL PROTECTED] wrote:
Hi,
Is there a r4-patch cooking for 2.6.13 ?
Is the requirement for not enabling 4k-stacks going away soon?
If I patch a vanilla kernel with r4, and sop using r4, would you say that the
changes I introduced by patching are rather safe to
http://it.slashdot.org/it/05/08/29/2241243.shtml?tid=109tid=218
Looks like MSFT will be beating Linux to the nextgen FS punch after all. ;)
Someone might want to update the information on reiser4 at:
http://en.wikipedia.org/wiki/Comparison_of_file_systems
and
http://en.wikipedia.org/wiki/Reiser4
A fair bit of information is missing/out of date it seems.
of 1) a new key that its children
would not inherit
touch /proc/1/keys/inheritable/1893410984328098094321
would give init a new key that is children WOULD inherit.
Not sure what the permissions on that keys directory would be, I guess 700.
Hans
Gregory Maxwell wrote:
On 8/18/05
On 8/18/05, Hans Reiser [EMAIL PROTECTED] wrote:
but the idea is to use keys instead of standard unix permissions
I think you need to store keys in a per process place, and allow
specifying whether children of a process inherit the keys somehow.
Oh, slick!
I did not previously catch
On 8/16/05, Christian Iversen [EMAIL PROTECTED] wrote:
Are there independent implementations of QT?
Well... Google harmony project qt.
:)
I think in reality it would be reasonable to handle this like the
Beagle search engine handles it's metadata.. Either you enable
extended attrs in your
On 8/11/05, PFC [EMAIL PROTECTED] wrote:
Well, but then you have to tell postgres that it can assume these things
about reiser4.
you can already set the sync mode in the config file to a llot of
different choices, like fdatasync, fsync, O_SYNC, etc, so a reiser4 option
would be
On 8/8/05, Hans Reiser [EMAIL PROTECTED] wrote:
I should add that fsync performance has not been worked on yet, which is
surely why postgres performance is poor.
Hans, I'm on the postgresql hackers list (although I don't really have
a voice there, so I can't really speak much for reiser4
On 8/8/05, David Masover [EMAIL PROTECTED] wrote:
Gregory Maxwell wrote:
On 8/8/05, Hans Reiser [EMAIL PROTECTED] wrote:
If ever you are looking for a killer app for Reiser4 that people who
don't care about the visionary stuff will care about:
Define visionary?
I can name a few
On 8/8/05, David Masover [EMAIL PROTECTED] wrote:
Reiser4 would be great if... is getting old. It is great, and it's
getting even better pretty fast.
And, by the way, if the transaction interface gets done, it's not just
databases that will benefit, but also small files. After all, what
On 8/8/05, David Masover [EMAIL PROTECTED] wrote:
Absolutely. I'm not knocking your idea, just wanted to clarify that
Reiser4 would be great if... is getting old. It is great, and it's
getting even better pretty fast.
(sorry for reply bloat)
I just wanted to point out.. that wasn't my
On 7/20/05, Edward Shishkin [EMAIL PROTECTED] wrote:
like other existing
ones. This will be a way to create cryptcompress files per superblock.
There is another
more flexible way (which is compatible with the previous one) to create
it per file/directory,
but it uses deprecated metas
On 6/28/05, Hubert Chan [EMAIL PROTECTED] wrote:
Isn't dm-crypt the new way of doing this?
Yes and no. dm-crypt is recommended over cryptoloop. But there is also
loop-AES, which is more secure (in some modes) than dm-crypt (currently).
There is now support for both LRW-AES and ESSIV in the
On 6/27/05, Hans Reiser [EMAIL PROTECTED] wrote:
. But nevertheless it didn't survive, as like V3, with time V4 became
slower and slower. In this case no year was needed, but just one month or
alike. So end of test...but in fact I'll give V4 another go in the near
future.
Interesting that it
On 6/27/05, Horst von Brand [EMAIL PROTECTED] wrote:
Wonderful! I carefully transparently encrypt my secret files, so
/everybody/ can read them! Now /that/ is progress!
All of this side feature argument is completely offtopic for the
inclusion of reiser4, but oh well.
In any case, the real use
On 6/25/05, Hans Reiser [EMAIL PROTECTED] wrote:
I wonder if Apple is a better
social environment for developers these days than Linux? It would be
fun to work with Steve Jobs, he has such a sense of vision and a delight
in new things. He hires good people too; Dominic Giampaolo is really
On Thu, 17 Feb 2005 23:28:09 -0500, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
On the flip side, hash functions like MD5 or the SHA family are fairly
bulletproof,
but are essentially impossible to develop an incremental update for (if there
existed a fast incremental update for the hash
On Fri, 18 Feb 2005 17:09:00 -0500, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
On Fri, 18 Feb 2005 08:36:51 EST, Gregory Maxwell said:
Tree hashes.
Divide the file into blocks of N bytes. Compute size/N hashes.
Group hashes into pairs. Compute N/2 N' hashes, this is fast because
hashes
Anyone ever given a though to adding support to reiserfs to store a
cryptographic checksum along with a file?
The idea is that files get a hidden attribute that contains their SHA1 hash.
If the file is modified, the hash is marked as 'unclean'. A trusted
cleaner comes by eventually and hashes
52 matches
Mail list logo
