On Tuesday 29 May 2007 07:36:13 Toby Thain wrote:
but you can't
mention using reiserfs in mixed company without someone accusing
you of
throwing your data away.
People who repeat this rarely have any direct experience of Reiser;
they repeat what they've heard; like all myths and
On Wednesday 30 May 2007 11:42:01 Toby Thain wrote:
But does it cause data loss? One usually sees claims that reiserfs
ate my data, or I heard reiserfs ate somebody's data, but without
supplying a root cause - bad memory? powerfail? bad disk? etc.
Power failure shouldn't kill a filesystem,
On Wednesday 30 May 2007 12:22:17 devsk wrote:
I have used R4 for a year now and I have had to reset my PC,
troubleshooting problems with vmware/mythtv/cisco vpn client/nvidia, so
many times that its not even funny! And R4 didn't give me any problems even
once. It boots right up, without any
On Wednesday 30 May 2007 11:02:26 Vladimir V. Saveliev wrote:
Ordinarily I like to help debug things, but not at the risk of my data.
Maybe I'll try again later, and see if I can reproduce it in a VM or
somewhere safe...
that would be great, thanks
Keep in mind, it's unlikely, given I
Finally set up network logging: kernel - syslog-ng - TCP (crossover)
- syslog-ng (other box) - log file. This time, I actually caught
something from the crash. It may be hardware-related, but I thought I'd
report it here this time because the crash was definitely in Reiser4
code. This may or
Azureus had a problem. Once it got up to a good clip downloading, it
would thrash the disk. It would thrash the disk, and the system, so
hard that even web browsing was difficult, due to disk access being
many, many times slower than Internet access, even an Internet which is
being hogged by
Konstantin Münning wrote:
David Masover wrote:
(snip)
It shouldn't be touching the disk AT ALL when there's over a gig of FREE
RAM (as in, neither buffer nor cache nor actually used yet), and the
file I'm attempting to download is less than 200 megs. I tried an
strace, but as I am not at all
Alexander Zarochentsev wrote:
I guess futex (, FUTEX_WAIT, ) calls can be ignored in this analysis.
They just wait another threat to call futex(, FUTEX_WAKE, ).
Interesting to find that thread and look what it was doing before
FUTEX_WAKE? Or FUTEX_WAIT returns ETIMEDOUT?
It probably would
Alexey Polyakov wrote:
On 9/20/06, Łukasz Mierzwa [EMAIL PROTECTED] wrote:
It's been proven that flushes are doing much more job then they should.
Not so long ago someone send a trace of block device io accesess during
reiser4 work and someone anylized it and said that some files or parts of
Alexey Polyakov wrote:
On 9/19/06, David Masover [EMAIL PROTECTED] wrote:
When I have over a
gig of RAM free (not even buffer/cache, but _free_), and am trying to
download anything over BitTorrent, even if it's less than 200 megs, the
disk thrashes so badly that the system is really only
Vladimir V. Saveliev wrote:
Hello
On Tuesday 19 September 2006 05:12, Jack Byer wrote:
Short summary: Will a resize program for reiser4 be available within the
next six months?
Currently nobody works on that. So, I guess it is not very likely that
reiser4.resize will be created within next
Vladimir V. Saveliev wrote:
while there is no fix currently for this problem you can solve the problem by
expanding underlaying device.
Just curious, could it also be fixed by mounting the FS, freeing up some
space, then retrying the FSCK? Or is the FS unusable?
Quinn Harris wrote:
On Thursday 14 September 2006 23:15, Toby Thain wrote:
On 14-Sep-06, at 6:23 PM, David Masover wrote:
Quinn Harris wrote:
On Thursday 14 September 2006 13:55, David Masover wrote:
...
That is a good point. Recording the disk layout before and after
to compare relative
Peter wrote:
Using: gentoo
kernel 2.6.17.11 with beyond patchset
reiser patch 2.6.17-3
reiser4progs 1.0.5
At the end of the gentoo shutdown script is a short function which
remounts / as ro.
There's also one in the Gentoo startup script, which attempts to remount
/ ro, then remount it rw. I
Ric Wheeler wrote:
David Masover wrote:
Hans Reiser wrote:
Ric Wheeler wrote:
Having mkfs ignore bad writes would seem to encourage users to create
a new file system on a disk that is known to be bad most likely not
going to function well. If a user ever has a golden opportunity
Ric Wheeler wrote:
David Masover wrote:
Why do you presume to make this decision for users?
It's not a decision that I want to make for users, it is a decision that
Hans and his team need to make about how best to spend their limited
resources.
Agreed. It's not important if it takes
Hans Reiser wrote:
Ric Wheeler wrote:
Having mkfs ignore bad writes would seem to encourage users to create
a new file system on a disk that is known to be bad most likely not
going to function well. If a user ever has a golden opportunity to
toss a drive in the trash, it is when they
[EMAIL PROTECTED] wrote:
On Mon, 04 Sep 2006 23:33:27 +0400, Vladimir V. Saveliev said:
after unclean shutdown journal reply is necessary to return reiserfs to
consistent state. Maybe GRUB did not do that?
A case can be made that GRUB should be keeping its grubby little paws off
the
Peter wrote:
On the namesys.com FAQ page, it is recommended that 0 0 be placed at the
end of the fstab lines for reiserfs partitions. I have two questions:
1) does this recommendation also apply for reiser4?
2) why is this recommendation made? Is it unnecessary to routinely check
reiser
Peter wrote:
On Fri, 01 Sep 2006 17:35:29 -0500, David Masover wrote:
Peter wrote:
2) I did run badblocks on the dest, and it was clean. 3) I am using the
patch from 2.6.17.3 and in my kernel, I have full preempt and cfq
scheduling.
What about the kernel on the livecd?
Anticipatory
Vladimir V. Saveliev wrote:
Hello
On Friday 01 September 2006 22:23, Peter wrote:
Perhaps this has been mentioned before. If so, sorry. IMHO, it would be
useful to integrate a call to badblocks in the fsck/mkfs.reiser* programs
so that more thorough disk checking can be done at format time.
Peter wrote:
2) I did run badblocks on the dest, and it was clean. 3) I am using the
patch from 2.6.17.3 and in my kernel, I have full preempt and cfq
scheduling.
What about the kernel on the livecd?
Peter wrote:
On Fri, 01 Sep 2006 17:27:20 -0500, David Masover wrote:
snip...
both mkfs.reiserfs and fsck.reiserfs have -B option to accept list of
bad blocks. We thought that should be enough.
It really should. Why bother with a patch? Just write a wrapper script
that runs badblocks
Clemens Eisserer wrote:
But speaking of single threadedness, more and more desktops are shipping
with ridiculously more power than people need. Even a gamer really
Will the LZO compression code in reiser4 be able to use multi-processor
systems?
Good point, but it wasn't what I was talking
PFC wrote:
Maybe, but Reiser4 is supposed to be a general purpose filesystem
talking about its advantages/disadvantages wrt. gaming makes sense,
I don't see a lot of gamers using Linux ;)
There have to be some. Transgaming seems to still be making a
successful business out of making
Nigel Cunningham wrote:
Hi.
On Tue, 2006-08-29 at 06:05 +0200, Jan Engelhardt wrote:
Hmm. LZO is the best compression algorithm for the task as measured by
the objectives of good compression effectiveness while still having very
low CPU usage (the best of those written and GPL'd, there is a
PFC wrote:
Would it be, by any chance, possible to tweak the thing so that
reiserfs plugins become kernel modules, so that the reiserfs core can be
put in the kernel without the plugins slowing down its acceptance ?
I don't see what this has to do with cryptoapi plugins -- those are
Gregory Maxwell wrote:
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
Hans Reiser wrote:
David Masover wrote:
John Carmack is pretty much the only superstar programmer in video
games, and after his first fairly massive attempt to make Quake 3 have
two threads (since he'd just gotten a dual-core machine to play with)
actually resulted in the game running some 30
Toby Thain wrote:
Gamer systems, whether from coder's or player's p.o.v., would appear
fairly irrelevant to reiserfs and this list. I'd trust Carmack's eye
candy credentials but doubt he has much to say about filesystems or
server threading...
Maybe, but Reiser4 is supposed to be a general
Andrew Morton wrote:
On Sun, 27 Aug 2006 04:34:26 +0400
Alexey Dobriyan [EMAIL PROTECTED] wrote:
The patch below is so-called reiser4 LZO compression plugin as extracted
from 2.6.18-rc4-mm3.
I think it is an unauditable piece of shit and thus should not enter
mainline.
Like lib/inflate.c
Jeff Mahoney wrote:
When a file system becomes fragmented (using MythTV, for example), the
bigalloc window searching ends up causing huge performance problems. In
a file system presented by a user experiencing this bug, the file system
was 90% free, but no 32-block free windows existed on
Marcos Dione wrote:
On Mon, Aug 21, 2006 at 08:23:30PM -0500, David Masover wrote:
it would be better to create a backup on a spare bigger partition
using dd_rescue (pad not recoverable zones with zeroes), then run
fsck on the created image.
unluckly I can't. it's a 160 GiB partition and I
Jeff Mahoney wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Masover wrote:
Jeff Mahoney wrote:
When a file system becomes fragmented (using MythTV, for example), the
bigalloc window searching ends up causing huge performance problems. In
a file system presented by a user
Marcos Dione wrote:
it would be better to create a backup on a spare bigger partition
using dd_rescue (pad not recoverable zones with zeroes), then run
fsck on the created image.
unluckly I can't. it's a 160 GiB partition and I don't have spare
space.
How much spare space do you have?
Francisco Javier Cabello wrote:
Hello,
I have been 'googling' and I have found a lot of people warning about the
problems with IDE write cache and journaling filesystems.
These problems exist with ANY filesystem, journaling or not. They also
exist with no filesystem at all.
Should I
Hans Reiser wrote:
Ingo Bormuth wrote:
#df:
/dev/hda8 6357768 3478716 2879052 55% /cache
Before doing so, the partition was 90% full.
The performance difference between 90% full and 55% full will be large
on every filesystem. When we ship a repacker, that will be less
Edward Shishkin wrote:
Tom Reinhart wrote:
Anyone with serious need for data integrity already uses RAID, so why
add brand new complexity for a solved problem?
RAID is great at recovering data, but not detecting errors. File
system can detect errors with checksum. What is missing is an API
Edward Shishkin wrote:
David Masover wrote:
Edward Shishkin wrote:
Tom Reinhart wrote:
Anyone with serious need for data integrity already uses RAID, so
why add brand new complexity for a solved problem?
RAID is great at recovering data, but not detecting errors. File
system can detect
Vesa Kaihlavirta wrote:
Incidentally, I've witnessed similar behaviour in various simple tasks,
e.g. writing
entries to an sqlite database, or receiving mail from pop3 in thunderbird.
Sounds like fsync issues. That is being worked on.
Łukasz Mierzwa wrote:
Dnia Thu, 10 Aug 2006 20:48:59 +0200, David Masover [EMAIL PROTECTED]
napisał:
Vesa Kaihlavirta wrote:
Incidentally, I've witnessed similar behaviour in various simple tasks,
e.g. writing
entries to an sqlite database, or receiving mail from pop3 in
thunderbird
Jan Engelhardt wrote:
Yes, it looks like a business of node plugin, but AFAIK, you
objected against such checks:
Did I really? Well, I think that allowing users to choose whether to
checksum or not is a reasonable thing to allow them. I personally would
skip the checksum on my computer, but
Andreas Schäfer wrote:
On 02:28 Wed 09 Aug , Hans Reiser wrote:
Unfortunately, it's not one of which editors approve. It too easily
looks as though the writer is being influenced by the source.
If I were to do so, I'd risk being banned from publication.
Uhm... interesting. It's not
Hans Reiser wrote:
Pavel Machek wrote:
Yes, I'm afraid redundancy/checksums kill write speed,
they kill write speed to cache, but not to disk our compression
plugin is faster than the uncompressed plugin.
Regarding cache, do we do any sort of consistency checking for RAM, or
do
Christian Trefzer wrote:
On Sun, Aug 06, 2006 at 04:23:16PM +0200, Maciej Sołtysiak wrote:
There also is an issue with grub. The kernel alone is fine for creating
partitions
(or loop devices) but with grub not patched we can't install boot partitions.
No biggy,
I guess, but still a problem.
Maciej Sołtysiak wrote:
Hello David,
hi
I have built today an r4-patched ubuntu kernel package (yes, debs!)
Sounds good. I don't have an ubuntu to test with at the moment, though.
Please note, that this is done all under virtualization
(Microsoft Virtual PC).
Not to nitpick, but isn't
Maciej Sołtysiak wrote:
Hello David,
Tuesday, August 8, 2006, 1:23:01 AM, you wrote:
Sounds good. I don't have an ubuntu to test with at the moment, though.
Well, both MS Virtual PC and VMWare are free of charge, so installing
is a real snap.
Under what, though? I don't want MS crap on my
[EMAIL PROTECTED] wrote:
It seems that finding all the bits and pieces to do ext3 on-line
expansion has been a study in obfuscation. Somewhat surprising since
this feature is a must for enterprise class storage management.
Not really. Having people who can dig through the obfuscation is
Lexington Luthor wrote:
Bernd Schubert wrote:
An alternative might be a reiser4 fuse port. Has some advantages:
Please please no. The kernel people will use that as an argument for
keeping it out of the kernel.
They'll use anything as an argument for keeping it out of the kernel.
This one
Pavel Machek wrote:
On Tue 01-08-06 11:57:10, David Masover wrote:
Horst H. von Brand wrote:
Bernd Schubert [EMAIL PROTECTED] wrote:
While filesystem speed is nice, it also would be great
if reiser4.x would be very robust against any kind of
hardware failures.
Can't have both.
Why not? I
Tassilo Horn wrote:
[1] http://www.linux.com/article.pl?sid=06/07/31/1548201
From the article:
To complicate matters, Reiser4's approach lands the filesystem in the
middle of a longstanding convention of avoiding plugins in the kernel,
mainly to avoid architectural complications, but also
Clay Barnes wrote:
I like using a term that is already in an accepted part of the
kernel. Extensions might smack of plugins a bit much, and we're
trying to avoid just doing a s/plugins/extensions/ of the
arguments we're seeing now.
We could do that with almost anything:
Or just modules...
Clay Barnes wrote:
I think the core thing we have to have to win this argument is
a) A word that isn't *instantly* associated with banned things.
That'd be nice.
b) The ability to point to the technology to point to the design
and say look, Look, it's *impossible* to use this design to put
TongKe Xue wrote:
A really stupid question ... why not put Reiser4 in one of the BSDs?
And after it's got mainstream use, if it proves its worth, there'll be
more pressure for Linux to adopt.
It will likely take far more work to port it to BSD than it will to be
included in Linux. And
Russell Leighton wrote:
Is there a recovery mechanism, or do you just be happy you know there is
a problem (and go to backup)?
You probably go to backup anyway. The recovery mechanism just means you
get to choose the downtime to restore from backup (if there is
downtime), versus being
Theodore Tso wrote:
On Tue, Aug 01, 2006 at 11:55:57AM -0500, David Masover wrote:
If I understand it right, the original Reiser4 model of file metadata is
the file-as-directory stuff that caused such a furor the last big push
for inclusion (search for Silent semantic changes in Reiser4
Horst H. von Brand wrote:
Vladimir V. Saveliev [EMAIL PROTECTED] wrote:
On Tue, 2006-08-01 at 17:32 +0200, Åukasz Mierzwa wrote:
What fancy (beside cryptocompress) does reiser4 do now?
it is supposed to provide an ability to easy modify filesystem behaviour
in various aspects without
Alan Cox wrote:
Ar Maw, 2006-08-01 am 16:52 +0200, ysgrifennodd Adrian Ulrich:
WriteCache, Mirroring between 2 Datacenters, snapshotting.. etc..
you don't need your filesystem beeing super-robust against bad sectors
and such stuff because:
You do it turns out. Its becoming an issue more and
Vladimir V. Saveliev wrote:
Do you think that if reiser4 supported xattrs - it would increase its
chances on inclusion?
Probably the opposite.
If I understand it right, the original Reiser4 model of file metadata is
the file-as-directory stuff that caused such a furor the last big push
for
Horst H. von Brand wrote:
Bernd Schubert [EMAIL PROTECTED] wrote:
While filesystem speed is nice, it also would be great if reiser4.x would be
very robust against any kind of hardware failures.
Can't have both.
Why not? I mean, other than TANSTAAFL, is there a technical reason for
them
Christian Trefzer wrote:
On Mon, Jul 31, 2006 at 10:57:35AM -0500, David Masover wrote:
Wil Reichert wrote:
Any idea how the fragmentation resulting from re-syncing the tree
affects performance over time?
Yes, it does affect it a lot. I have no idea how much, and I've never
benchmarked
Theodore Tso wrote:
Ah, but as soon as the repacker thread runs continuously, then you
lose all or most of the claimed advantage of wandering logs.
[...]
So instead of a write-write overhead, you end up with a
write-read-write overhead.
This would tend to suggest that the repacker should
Alan Cox wrote:
Ar Maw, 2006-08-01 am 11:44 -0500, ysgrifennodd David Masover:
Yikes. Undetected.
Wait, what? Disks, at least, would be protected by RAID. Are you
telling me RAID won't detect such an error?
Yes.
RAID deals with the case where a device fails. RAID 1 with 2 disks can
Gregory Maxwell wrote:
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
Ric Wheeler wrote:
Alan Cox wrote:
Ar Maw, 2006-08-01 am 16:52 +0200, ysgrifennodd Adrian Ulrich:
WriteCache, Mirroring between 2 Datacenters, snapshotting.. etc..
you don't need your filesystem beeing super-robust against bad sectors
and such stuff because:
You do it turns out. Its
Ian Stirling wrote:
David Masover wrote:
David Lang wrote:
On Mon, 31 Jul 2006, David Masover wrote:
Oh, I'm curious -- do hard drives ever carry enough
battery/capacitance to cover their caches? It doesn't seem like it
would be that hard/expensive, and if it is done that way, then I
Nate Diller wrote:
On 8/1/06, David Masover [EMAIL PROTECTED] wrote:
Vladimir V. Saveliev wrote:
I could be entirely wrong, though. I speak for neither
Hans/Namesys/reiserfs nor LKML. Talk amongst yourselves...
i should clarify things a bit here. yes, hans' goal
Hans Reiser wrote:
I think that most of our problem is that we are too socially insulated
from lkml. They are a herd, and decide things based on what thoughts
echo most loudly.
To be fair, it's not the whole lkml you have to convince, just the few
people directly responsible for filesystems
Wil Reichert wrote:
=)
That was sorta the plan.
Any idea how the fragmentation resulting from re-syncing the tree
affects performance over time?
Try to post replies at the bottom, or below the context.
Yes, it does affect it a lot. I have no idea how much, and I've never
benchmarked it,
Jan-Benedict Glaw wrote:
On Mon, 2006-07-31 17:59:58 +0200, Adrian Ulrich [EMAIL PROTECTED] wrote:
A colleague of mine happened to create a ~300gb filesystem and started
to migrate Mailboxes (Maildir-style format = many small files (1-3kb))
to the new LUN. At about 70% the filesystem ran out of
Matthias Andree wrote:
Adrian Ulrich schrieb am 2006-07-31:
Why are a lot of Solaris-people using (buying) VxFS? Maybe because UFS
also has such silly limitations? (..and performs awkward with trillions
of files..?..)
Well, such silly limitations... looks like they are mostly hot air
spewn
Jan-Benedict Glaw wrote:
On Mon, 2006-07-31 12:17:12 -0700, Clay Barnes [EMAIL PROTECTED] wrote:
On 20:43 Mon 31 Jul , Jan-Benedict Glaw wrote:
On Mon, 2006-07-31 20:11:20 +0200, Matthias Andree [EMAIL PROTECTED] wrote:
Jan-Benedict Glaw schrieb am 2006-07-31:
[Crippled DMA writes]
David Lang wrote:
On Mon, 31 Jul 2006, David Masover wrote:
Probably. By the time a few KB of metadata are corrupted, I'm
reaching for my backup. I don't care what filesystem it is or how
easy it is to edit the on-disk structures.
This isn't to say that having robust on-disk structures
Alan Cox wrote:
Ar Llu, 2006-07-31 am 17:00 -0400, ysgrifennodd Gregory Maxwell:
Are you sure that you aren't commenting on cases where Reiser3 alerts
the user to a critical data condition (via a panic) which leads to a
trouble report while ext3 ignores the problem which suppresses the
Maciej Sołtysiak wrote:
Hello David,
- it is more expensive to:
a) succeed at kernel inclusion
b) argue
c) waste time
You must be new here...
Options B and C are all that ever seems to happen when reiserfs-list and
lkml collide.
Is option A possible? The speed of a nonworking
Matthias Andree wrote:
On Mon, 31 Jul 2006, Nate Diller wrote:
this is only a limitation for filesystems which do in-place data and
metadata updates. this is why i mentioned the similarities to log
file systems (see rosenblum and ousterhout, 1991). they observed an
order-of-magnitude
Theodore Tso wrote:
On Mon, Jul 31, 2006 at 08:31:32PM -0500, David Masover wrote:
So you use a repacker. Nice thing about a repacker is, everyone has
downtime. Better to plan to be a little sluggish when you'll have
1/10th or 1/50th of the users than be MUCH slower all the time.
Actually
Timothy Webster wrote:
Different users have different needs.
I'm having trouble thinking of users who need an FS that doesn't need a
repacker.
The disk error problem, though, you're right -- most users will have to
get bitten by this, hard, at least once, or they'll never get the
David Lang wrote:
On Mon, 31 Jul 2006, David Masover wrote:
Oh, I'm curious -- do hard drives ever carry enough
battery/capacitance to cover their caches? It doesn't seem like it
would be that hard/expensive, and if it is done that way, then I think
it's valid to leave them on. You could
David Lang wrote:
On Mon, 31 Jul 2006, David Masover wrote:
And perhaps a
really good clustering filesystem for markets that
require NO downtime.
Thing is, a cluster is about the only FS I can imagine that could
reasonably require (and MAYBE provide) absolutely no downtime.
Everything
David Lang wrote:
On Mon, 31 Jul 2006, David Masover wrote:
Aha, so back to the usual argument: UPS! It takes a fraction of a
second to flush that cache.
which does absolutly no good if someone trips over the power cord, the
fuse blows in the power supply, someone yanks the drive out
Łukasz Mierzwa wrote:
Dnia Sat, 29 Jul 2006 20:31:59 +0200, David Masover [EMAIL PROTECTED]
napisał:
Nikita Danilov wrote:
As you see, ext2 code already has multiple file plugins, with
persistent plugin id (stored in i_mode field of on-disk struct
ext2_inode).
Aha! So here's another
Christian Trefzer wrote:
On Sun, Jul 30, 2006 at 11:39:42PM +0200, Christian Trefzer wrote:
In order to avoid having to pull the whole tree via rsync again, you
might want to grab my script from the list and adapt it to your needs.
Of course, you can tar it up manually instead. Silly me, but
Christian Trefzer wrote:
Hi,
I booted 2.6.18-rc2-mm1 today and later filled up my /opt partition by
accident, and guess what, reiser4 did not screw up : D
Hmm, I'm curious, though... How does it react to a few billion files?
Sorry, I can't test this, but I will be testing MythTV, if not
Arjan van de Ven wrote:
Most users not only cannot patch a kernel, they don't know what a patch
is. It most certainly does.
obviously you can provide complete kernels, including precompiled ones.
Most distros have a yum or apt or similar tool to suck down packages,
it's trivial for
Hans Reiser wrote:
David Masover wrote:
If indeed it can be changed easily at all. I think the burden is on
you to prove that you can change it to be more generic, rather than
saying Well, we could do it later, if people want us to...
None of the filesystems other than reiser4 have any
Nikita Danilov wrote:
As you see, ext2 code already has multiple file plugins, with
persistent plugin id (stored in i_mode field of on-disk struct
ext2_inode).
Aha! So here's another question: Is it fair to ask Reiser4 to make its
plugins generic, or should we be asking ext2/3 first?
Sarath Menon wrote:
On Saturday 29 July 2006 23:41, David Masover wrote:
I know Gentoo handles this automatically (emerge nvidia-kernel).
I hate to say this again, but its not automatically. It requires more
My point is, there's a fairly large group of users who would be willing
to do
Horst H. von Brand wrote:
Jeff Garzik [EMAIL PROTECTED] wrote:
[...]
It is then simple to follow that train of logic: why not make it easy
to replace the directory algorithm [and associated metadata]? or the
file data space management algorithms? or even the inode handling?
why not allow
.
And no one else cares what your finances are. Not out of compassion,
but out of practicality. For instance, it would be a huge financial
benefit to me if the kernel displayed, in big bold letters while
booting, that DAVID MASOVER WROTE THIS! (I'm sure Linus knows what I'm
talking about
Hans Reiser wrote:
plugins if not for us. Our plugins affect no one else. Our
self-contained code should not be delayed because other people delayed
And at the moment, I can still use Reiser4. If I ever make a distro, I
will include Reiser4 support, probably as the default FS. That will
Jeff Garzik wrote:
Pavel Machek wrote:
Hi!
of the story for me. There's nothing wrong about focusing on newer
code,
but the old code needs to be cared for, too, to fix remaining issues
such as the can only have N files with the same hash value.
Requires a disk format change, in a filesystem
Maciej Sołtysiak wrote:
Hello David,
Thursday, July 27, 2006, 3:19:15 AM, you wrote:
I'm not arguing for closed source, I'm just saying that once you open,
there's no going back. Many times it's a good thing, but sometimes you
A sidenote.
Reiser4 is open and still we don't see people
Matthias Andree wrote:
On Tue, 25 Jul 2006, David Masover wrote:
Matthias Andree wrote:
On Tue, 25 Jul 2006, Denis Vlasenko wrote:
I, on the contrary, want software to impose as few limits on me
as possible.
As long as it's choosing some limit, I'll pick the one with fewer
surprises
Matthias Andree wrote:
On Tue, 25 Jul 2006, Denis Vlasenko wrote:
I, on the contrary, want software to impose as few limits on me
as possible.
As long as it's choosing some limit, I'll pick the one with fewer
surprises.
Running out of inodes would be pretty surprising for me.
But then,
Russell Cattelan wrote:
On Sun, 2006-07-23 at 01:20 -0600, Hans Reiser wrote:
Jeff, I think that a large part of what is going on is that any patch
that can be read in 15 minutes gets reviewed immediately, and any patch
that is worked on for 5 years and then takes a week to read gets
[...]
It
Timothy Webster wrote:
WARNING, a users point of view ;)
Everything is a file, including a directory.
Being able to view files as directories is not just a
nice to have thing. It is actually required if we are
going to manage changesets of odf files.
The lkml people will tell you that this
Mike Benoit wrote:
Thanks for all your hard work, I'm sure many other MythTV users will be
appreciate it.
As a future MythTV user a bit late to this discussion, I'm curious --
was this Reiser3 or 4? Are there any known MythTV issues with v4? I
say this because the box with my capture card is
Horst H. von Brand wrote:
18GiB = 18 million KiB, you do have a point there. But 40 million files on
that, with some space to spare, just doesn't add up.
Right, ok...
Here's a quick check of my box. I've explicitly stated which root-level
directories to search, to avoid nfs mounts, chrooted
Hans Reiser wrote:
to use as his default. Now that we paid the 5 year development price
tag to get everything as plugins, we can now upgrade in littler pieces
than any other FS. Hmm, I need a buzz phrase, its not extreme
programming, maybe moderate programming. Does that sound exciting to
1 - 100 of 447 matches
Mail list logo
