-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Reiser wrote:
[EMAIL PROTECTED] wrote:
tarball/zipfile. Nobody ever suggested that you would actually want to.
Besides, your point was that you could not run make inside of a kernel
Umm, try it when we have it working, on a 1-4GB
On Mon, 27 Jun 2005 00:57:54 CDT, David Masover said:
In one of three possible settings for the imaginary zipfile plugin, yes.
But if we're talking about a kernel source tree, how many of us
actually build zipfiles/tarballs of their kernel source trees, rather
than unpack existing ones?
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Horst von Brand wrote:
David Masover [EMAIL PROTECTED] wrote:
Kyle Moffett wrote:
On Jun 26, 2005, at 22:37:48, David Masover wrote:
[...]
That just means the zip plugin has to be more carefully written than I
thought. It would have to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Horst von Brand wrote:
David Masover [EMAIL PROTECTED] wrote:
Hans Reiser wrote:
[...]
Reiser4 plugins are not per user, but per kernel. They are compiled
in. The model is intended to ease the development process, nothing
more.
On Mon, 27 Jun 2005 00:54:17 CDT, David Masover said:
There has been some mention of inheritance, but I've forgotten how
that's supposed to work. If there's some sort of inheritance where
children inherit properties of their parent directory, and also inherit
changes to those properties,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
On Mon, 27 Jun 2005 00:57:54 CDT, David Masover said:
In one of three possible settings for the imaginary zipfile plugin, yes.
But if we're talking about a kernel source tree, how many of us
actually build
Hi,
seems one of my server (amd64/bi-opteron) running reiser4 on top of
raid6 software oops-ed this week-end,
here is the output, maybe it's usefull for you.
the config can be downloaded from
http://www-fourier.ujf-grenoble.fr/~mmarcha/config-2.6.12-rc5
tell me if you need more infos.
I will
On Mon, 27 Jun 2005 01:27:25 CDT, David Masover said:
I back up with rsync, actually.
Doesn't matter what it is. You still need to define sane semantics for
it.. ;)
Speaking of backup, that's another nice place for a plugin. Imagine a
dump that didn't have to be of the entire FS, but
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
On Mon, 27 Jun 2005 01:27:25 CDT, David Masover said:
[...]
Speaking of backup, that's another nice place for a plugin. Imagine a
dump that didn't have to be of the entire FS, but rather an arbitrary
tree... That might be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
On Mon, 27 Jun 2005 00:54:17 CDT, David Masover said:
There has been some mention of inheritance, but I've forgotten how
that's supposed to work. If there's some sort of inheritance where
children inherit properties of
On Sat, Jun 25 2005, Pekka Enberg wrote:
Hi,
On Thu, 2005-06-23 at 21:32 +0200, Jens Axboe wrote:
then it's impossible to know which one it is without the identical
source at hand.
In which case, debugging is risky IMO (the source code could have
changed a lot).
That's not an
[EMAIL PROTECTED] wrote:
For more fun, consider how you can write 1 megabyte of data to a file,
lseek to the beginning and start writing again - and you go over quota
on the *second* write even though you're over-writing already existing
data. Can happen if you're compressing, and the second
On Thu, 2005-06-23 at 21:32 +0200, Jens Axboe wrote:
That said, I don't like the reiser name-number style. If you must do
something like this, mark responsibility by using a named identifier
covering the layer in question instead.
assert(trace_hash-89, is_hashed(foo) !=
On Mon, 2005-06-27 at 09:28 +0200, Andi Kleen wrote:
You can just dump the expression (with #argument). That is what
traditional userspace assert did forever.
It won't help for BUG_ON(a || b || c || d || e) but these
are bad style anyways and should be avoided.
Sounds good to me. Jens,
On Mon, Jun 27, 2005 at 10:49:19AM +0300, Pekka J Enberg wrote:
On Mon, 2005-06-27 at 09:28 +0200, Andi Kleen wrote:
You can just dump the expression (with #argument). That is what
traditional userspace assert did forever.
It won't help for BUG_ON(a || b || c || d || e) but these
are
On Mon, 27 June 2005 10:49:19 +0300, Pekka J Enberg wrote:
#ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (unlikely((condition)!=0)) BUG(); }
while(0)
+#define BUG_ON(condition) do { \
+ if (unlikely((condition) != 0)) { \
+ printk(kernel BUG '%s' at
On Sun, Jun 26, 2005 at 04:42:35PM -0700, Hans Reiser wrote:
I'm a bit confused about what you're saying here. What does the 'vector'
in all these expressions mean?
Was your word, I thought, for the *_operation structures.
We tend to use the term operation vectors, yes. But that's a
Related FS:
ReiserFS
Related Files:
fs/reiserfs/file.c
Bug description:
Make a ReiserFS partition in USB storage HDD, create a test file
with enough size(dd if=/dev/zero of=testfile bs=4096 count=1024).
Write a program, do:
int fd;
char buf[4096];
fd =
On Fri, Jun 24, 2005 at 11:41:21AM +0100, Alan Cox wrote:
More fundamentally - prototype things *out* of the main kernel. If
everyone was doing their prototyping in kernel Andrew Morton would by
now be a team of about 25
This is going semi off-topic but how then do you justify regression
that's
On Thu, Jun 23, 2005 at 11:34:50PM -0400, Horst von Brand wrote:
David Masover [EMAIL PROTECTED] wrote:
I think Hans (or someone) decided that when hardware stops working, it's
not the job of the FS to compensate, it's the job of lower layers, or
better, the job of the admin to replace the
Hello,
I was investigating Riser4 readdir() handling. As the result I've
realized the following:
1. repeatable readdir() calls should work well.
2. seekdir()/telldir() mustn't work. (because per_file readdir_pos
stores only the _last_ f_pos-{key, entry_no, position} mapping, so the
mapping
On Sunday 26 June 2005 21:02, Christoph Hellwig wrote:
On Wed, Jun 22, 2005 at 04:08:49AM -0500, David Masover wrote:
I've been reading a bit of history, and the reason Linux got so popular
in the first place was the tendency to include stuff that worked and
provided a feature people
On Mon, Jun 27, 2005 at 01:30:06PM +0400, Alexander Zarochentsev wrote:
-- procfs has seq_file and sysconfig interfaces below the VFS and l-k people
do not complain each day about layering violation ;-) Procfs is taken as an
example because it deals with objects of different types, actually
Markus Törnqvist wrote:
I can't find the original post I'm thinking about but
http://lkml.org/lkml/2005/5/16/68 says essentially the same thing.
The scheduler is being improved for better behaviour on complex
topologies like multi core + NUMA and multi level NUMA systems.
If Con's work had
On Monday 27 June 2005 13:42, Christoph Hellwig wrote:
On Mon, Jun 27, 2005 at 01:30:06PM +0400, Alexander Zarochentsev wrote:
-- procfs has seq_file and sysconfig interfaces below the VFS and l-k
people do not complain each day about layering violation ;-) Procfs is
taken as an example
Hello
On Mon, 2005-06-27 at 13:28, Artem B. Bityuckiy wrote:
Hello,
I was investigating Riser4 readdir() handling. As the result I've
realized the following:
1. repeatable readdir() calls should work well.
2. seekdir()/telldir() mustn't work. (because per_file readdir_pos
stores only
Location within a directory in reiser4 is logical number of entry within
the directory.
Yes, I know. It does not absolutely correctly handle the way when
dirents were deleted before and after the saved position.
Well, Nikita kindly answered my questions in IRC (unfortunately there
are few
On Mon, 27 Jun 2005, Andi Kleen wrote:
It won't work for me because it'll bloat the kernel .text
considerable. There is a reason why BUG is implemented
like it is. Compare it.
The assertion codes bloat the kernel all the same. So how about this
instead?
This patch adds a
On Mon, Jun 27, 2005 at 03:27:50PM +0300, Pekka J Enberg wrote:
On Mon, 27 Jun 2005, Andi Kleen wrote:
It won't work for me because it'll bloat the kernel .text
considerable. There is a reason why BUG is implemented
like it is. Compare it.
The assertion codes bloat the kernel all the
Hello
On Mon, 2005-06-27 at 16:09, Artem B. Bityuckiy wrote:
Location within a directory in reiser4 is logical number of entry within
the directory.
Yes, I know. It does not absolutely correctly handle the way when
dirents were deleted before and after the saved position.
Well, Nikita
On Mon, 27 June 2005 15:27:50 +0300, Pekka J Enberg wrote:
On Mon, 27 Jun 2005, Andi Kleen wrote:
It won't work for me because it'll bloat the kernel .text
considerable. There is a reason why BUG is implemented
like it is. Compare it.
The assertion codes bloat the kernel all the same. So
On Mon, Jun 27, 2005 at 12:21:38PM +0300, Markus T?rnqvist wrote:
On Thu, Jun 23, 2005 at 11:34:50PM -0400, Horst von Brand wrote:
David Masover [EMAIL PROTECTED] wrote:
I think Hans (or someone) decided that when hardware stops working, it's
not the job of the FS to compensate, it's the
Andi Kleen writes:
It's still useless - it is too bloated to turn on by default
and then if you need it you still won't have it. And when you
explicitely turn it on then you likely don't need it because
you control the source.
Hmm. Would a BUG_ON_WITH_TEXT be a better solution? The home-grown
On Mon, Jun 27, 2005 at 07:46:15PM +1000, Nick Piggin wrote:
The scheduler is being improved for better behaviour on complex
topologies like multi core + NUMA and multi level NUMA systems.
If Con's work had gone in first, then conversely these improvements
would have had to wait.
Or be merged in
Vladimir,
thanks for answer.
Vladimir Saveliev wrote:
for some reasons IRC server decided to not allow us to connect.
Well, switching to another server may help.
I guess between SEEKABLE_HASHED_DIR_PLUGIN_ID and HASHED_DIR_PLUGIN_ID?
yes, pardon.
SEEKABLE_HASHED_DIR_PLUGIN_ID should
On Mon, Jun 27, 2005 at 02:00:49AM -0500, David Masover wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
On Mon, 27 Jun 2005 01:27:25 CDT, David Masover said:
[...]
Speaking of backup, that's another nice place for a plugin. Imagine a
dump that didn't
Hello
On Mon, 2005-06-27 at 16:57, Artem B. Bityuckiy wrote:
Vladimir,
thanks for answer.
Vladimir Saveliev wrote:
for some reasons IRC server decided to not allow us to connect.
Well, switching to another server may help.
I guess between SEEKABLE_HASHED_DIR_PLUGIN_ID and
Vladimir Saveliev wrote:
I think from the beginning HASHED_DIR_PLUGIN_ID was not supposed to be
seekable. It changed later, HASHED_DIR_PLUGIN_ID became both seekable
and default in reiser4.
Well, this what I suspected... Would be nice to rename the plugins and
add more comments..
Thanks.
--
On Llu, 2005-06-27 at 10:18, Markus Törnqvist wrote:
Sure, other people merge design-breakers and bugs is NOT a justification
for merging Reiser4, of course, but Reiser4's track record has vastly
cleaned itself up.
The discussion is about merging from -mm, not into -mm. The merge into
-mm
On Mon, 27 Jun 2005 00:59:39 -0400, [EMAIL PROTECTED] said:
On Sun, 26 Jun 2005 23:10:43 EDT, Hubert Chan said:
On Sun, 26 Jun 2005 20:40:29 -0400, [EMAIL PROTECTED] said:
Oh, I'm waiting for the fun the first time somebody deploys a
plugin that has similar semantics to 'chmod g+s dirname/'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Weinehall wrote:
On Mon, Jun 27, 2005 at 02:00:49AM -0500, David Masover wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
On Mon, 27 Jun 2005 01:27:25 CDT, David Masover said:
[...]
Speaking of backup, that's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Theodore Ts'o wrote:
On Mon, Jun 27, 2005 at 12:21:38PM +0300, Markus T?rnqvist wrote:
On Thu, Jun 23, 2005 at 11:34:50PM -0400, Horst von Brand wrote:
David Masover [EMAIL PROTECTED] wrote:
I think Hans (or someone) decided that when hardware
On Mon, Jun 27, 2005 at 10:19:01AM -0500, David Masover wrote:
XFS has similar issues where it assumes that hardware has powerfail
interrupts, and that the OS can use said powerfail interrupt to stop
DMA's in its tracks on an power failure, so that you don't have
garbage written to key
On Mon, 27 Jun 2005 02:00:49 CDT, David Masover said:
Speaking of backup, that's another nice place for a plugin. Imagine a
dump that didn't have to be of the entire FS, but rather an arbitrary
tree... That might be a nice new archive format. I know Apple already
uses something like this
On Mon, 27 Jun 2005 02:07:46 CDT, David Masover said:
Exactly the same sort of thing - traditionally it's been more or less
ignored
in the system accounting, because A would usually average out to causing as
many I/Os as B did, and they were roughly equal in cost so it was a wash.
Even
Artem B. Bityuckiy wrote:
Location within a directory in reiser4 is logical number of entry within
the directory.
Yes, I know. It does not absolutely correctly handle the way when
dirents were deleted before and after the saved position.
Well, Nikita kindly answered my questions in IRC
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
On Mon, 27 Jun 2005 02:00:49 CDT, David Masover said:
Speaking of backup, that's another nice place for a plugin. Imagine a
dump that didn't have to be of the entire FS, but rather an arbitrary
tree... That might be a
On Mon, Jun 27, 2005 at 03:28:49PM +0400, Alexander Zarochentsev wrote:
not exactly. I meant that seq_file has its own VFS-like thing struct
seq_operations.
It's not that VFS-like, it's more a set of callback than actual methods.
But yes, if you're actually doing work at a significant lower
Steve, there is a remark about XFS below which you are going to be more
expert on.
Theodore Ts'o wrote:
Most Linux users are using PC-class hardware. And Ted's First Law of
PC-Class Hardware is: Most of it is crap. And then there's Ted's
Second Law, Too many system administrators don't do
Artem B. Bityuckiy wrote:
Vladimir Saveliev wrote:
I think from the beginning HASHED_DIR_PLUGIN_ID was not supposed to be
seekable. It changed later, HASHED_DIR_PLUGIN_ID became both seekable
and default in reiser4.
Well, this what I suspected... Would be nice to rename the plugins and
Hans Reiser wrote:
Steve, there is a remark about XFS below which you are going to be more
expert on.
Theodore Ts'o wrote:
XFS has similar issues where it assumes that hardware has powerfail
interrupts, and that the OS can use said powerfail interrupt to stop
DMA's in its tracks on an
On Mon, Jun 27, 2005 at 03:18:30PM -0500, Steve Lord wrote:
I presume Ted is referring to problems guaranteeing the integrity of
the journal at recovery time. I am coming into this without all the
available context, so I may be barking up the wrong tree In
particular, I am not sure how
Theodore Ts'o wrote:
On Mon, Jun 27, 2005 at 03:18:30PM -0500, Steve Lord wrote:
I presume Ted is referring to problems guaranteeing the integrity of
the journal at recovery time. I am coming into this without all the
available context, so I may be barking up the wrong tree In
particular,
Theodore Ts'o wrote:
On Mon, Jun 27, 2005 at 03:18:30PM -0500, Steve Lord wrote:
I presume Ted is referring to problems guaranteeing the integrity of
the journal at recovery time. I am coming into this without all the
available context, so I may be barking up the wrong tree In
particular,
On Friday 24 June 2005 23:46, Hans Reiser wrote:
David Masover wrote:
I was able to recover from bad blocks, though of course no Reiser that I
know of has had bad block relocation built in...
there was a patch somewhere. Vitaly, please comment.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vitaly Fertman wrote:
On Friday 24 June 2005 23:46, Hans Reiser wrote:
David Masover wrote:
I was able to recover from bad blocks, though of course no Reiser that I
know of has had bad block relocation built in...
there was a patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Theodore Ts'o wrote:
On Mon, Jun 27, 2005 at 10:19:01AM -0500, David Masover wrote:
[...]
Given a choice between changing filesystems or getting a Streamload
account, I choose Streamload. (streamload.com)
*If* you can afford the upload
On Sunday 26 June 2005 23:05, Hans Reiser wrote:
Reuben Farrelly wrote:
Hi Hans,
On 25/06/2005 12:38 a.m., Hans Reiser wrote:
fsck is better in V4 than it is in V3. Users should move from V3 to V4,
as V3 is obsolete. I agree on that Ted.
Perhaps before moving to V4,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kyle Moffett wrote:
On Jun 26, 2005, at 23:24:23, David Masover wrote:
Neither do I want the kernel to unzip it, because that just
introduces the
kernel to a whole series of normally application-level vulnerabilities.
That just means the
On Mon, Jun 27, 2005 at 12:46:23PM -0700, Hans Reiser wrote:
A difference between us is
that I tell them that with all the major linux filesystems (I include
XFS and JFS in this) it is by this time far more likely to be hardware
that caused corruption than the filesystem software, whereas I
Andrew asked me to put together a list of things that need to be done
before merging:
* VFS will dispatch directly to the method of the plugin for the
*_operations methods. This requires duplicating to all plugin methods
the common code currently used by all reiser4 plugins for a given
Steve Lord schrieb:
I see no way short of hardware fixes of avoiding the general problem of
a system failing in an ugly manner like this. Unless you write everything
to disk twice (i.e. journal all data), you can still end up with a
legitimate set of metadata, and the master copy of your
Hans Reiser [EMAIL PROTECTED] wrote:
Andrew asked me to put together a list of things that need to be done
before merging:
Thanks.
As I said to Hans, if we can get a list of bullet-point actions nailed down
and agreed to then we have an uncontroversial path to happiness and a
merge. Let's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kyle Moffett wrote:
On Jun 27, 2005, at 17:19:21, David Masover wrote:
Precisely. Come back when you have a good sturdy set of arguments.
See
the FUSE project (Also discussed in this thread), for better ideas
on how
to add strange
What happens when the ext3 inode tables get hit by sector damage? Like
us, ext3 has data munging if you hit the wrong thing, its just that our
sources of data munging are different in the details. Details matter
though, and so we are improving with each release, and V4 does have some
real
Markus Törnqvist wrote:
On Mon, Jun 27, 2005 at 07:46:15PM +1000, Nick Piggin wrote:
The scheduler is being improved for better behaviour on complex
topologies like multi core + NUMA and multi level NUMA systems.
If Con's work had gone in first, then conversely these improvements
would have
Prakash Punnoor 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 got slower with time. It
On Mon, 2005-06-27 at 17:40 -0700, Hans Reiser wrote:
Prakash Punnoor 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
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 06/28/05 01:06:54AM +0200, Prakash Punnoor wrote:
So I gave ext3 a try. Very robust, but at the same time slooow. I couldn't
bear it after some months. So I gave xfs another try. Yes, now it felt much
better. Still not that fast as reiserfs, IIRC, but better than the first time
I tried. I
On Mon, 27 Jun 2005 18:27:26 -0500, David Masover [EMAIL PROTECTED] said:
Kyle Moffett wrote:
I think the '...' is just a bad idea in general, because it breaks
tar and such. An interface like this might be simpler to design and
use:
# mkdir /attr
# mount -t attrfs attrfs /attr
On Mon, 2005-06-27 at 18:27 -0500, David Masover wrote:
Right on all points. Just remember that some change is good. Why do
we
have ALSA now? Everything a user can do with ALSA, they can do with
OSS, AFAIK.
Wrong, you have it backwards. The ALSA API is a superset of the OSS
API.
Hans Reiser [EMAIL PROTECTED] writes:
* metafiles should be disabled until we can present code that works
right. Half the list thinks we cannot solve the cycles problem ever.
Disable metafiles and postpone problem until working code, or the
failure to produce it, makes it possible to do
On Mon, 27 Jun 2005 22:59:24 -0400, Kyle Moffett [EMAIL PROTECTED] said:
On Jun 27, 2005, at 22:21:35, Hubert Chan wrote:
On Mon, 27 Jun 2005 18:27:26 -0500, David Masover
[EMAIL PROTECTED] said:
Kyle Moffett wrote:
[...]
/attr/fd/$FD_NUM == '...' directory for a filedescriptor
Jim Crilly schrieb:
On 06/28/05 01:06:54AM +0200, Prakash Punnoor wrote:
So I gave ext3 a try. Very robust, but at the same time slooow. I couldn't
bear it after some months. So I gave xfs another try. Yes, now it felt much
better. Still not that fast as reiserfs, IIRC, but better than the
On 06/28/05 06:03:25AM +0200, Prakash Punnoor wrote:
Jim Crilly schrieb:
On 06/28/05 01:06:54AM +0200, Prakash Punnoor wrote:
So I gave ext3 a try. Very robust, but at the same time slooow. I couldn't
bear it after some months. So I gave xfs another try. Yes, now it felt much
better.
Agree with most of the stuff you wrote.
On Tue, 28 Jun 2005 00:38:38 -0400, Kyle Moffett [EMAIL PROTECTED] said:
On Jun 27, 2005, at 23:45:00, Hubert Chan wrote:
I think for most people on the reiser-fs list, the '...' directory
represents an interface to many things including
- automatic
77 matches
Mail list logo
