-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gregory Maxwell wrote:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hubert Chan wrote:
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
On Tue, Jun 28, 2005 at 10:23:19AM +1000, Nick Piggin wrote:
The scheduler interfaces are probably among the most stable
in the kernel. Con was talking about internal implementation.
Hmm, I'm by no means a kernel developer, but looking at the
patches, it looked like the functions were just
On Tue, Jun 28, 2005 at 09:44:59AM -0400, Horst von Brand wrote:
No. But just relying on perfect hardware and concientious sysadmins is
reckless. Hardware /is/ flaky, sysadmins /are/ (sometimes) lazy (and
besides, today they are increasingly just plain Joe Sixpack users). Also,
backing up a few
On Tue, 2005-06-28 at 23:47 +0300, Markus Törnqvist wrote:
On Tue, Jun 28, 2005 at 09:44:59AM -0400, Horst von Brand wrote:
No. But just relying on perfect hardware and concientious sysadmins is
reckless. Hardware /is/ flaky, sysadmins /are/ (sometimes) lazy (and
besides, today they are
On Tue, 28 Jun 2005 15:22:55 -0500, David Masover [EMAIL PROTECTED] said:
Come to think of it, that changes the proposal a bit. You need a
different way to access the meta-dir for files than for directories,
if we're going to support /meta/vfs. No biggie:
to comply further increases the
lateness of Reiser4 in mainline kernels. Ego involvement is noise.
My observations being what they are, may I suggest that this thread die,
in favor of more eyes and in-depth current code analysis help in Re:
reiser4 merging action list? Higher utility function; higher
Andrew Morton wrote:
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
-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
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
[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 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
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
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
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, 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
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
Gregory Maxwell wrote:
On 6/26/05, Lincoln Dale [EMAIL PROTECTED] wrote:
the l-k community have asked YOU may times. any lack of response isn't
because of the kernel cabal .. its because YOU are refusing to entertain
any notion that what Reiser4 has implemented is unpalatable to the
kernel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lincoln Dale wrote:
[...]
this is the WHOLE point of standardization .. i don't think its that
Reiser4's EAs offer any more or less capabilities than standard EAs -
They do. Reiser4's EAs can look like any other object -- files,
folders,
David Masover wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lincoln Dale wrote:
[...]
this is the WHOLE point of standardization .. i don't think its that
Reiser4's EAs offer any more or less capabilities than standard EAs -
They do. Reiser4's EAs can look like any other
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lincoln Dale wrote:
David Masover wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lincoln Dale wrote:
[...]
this is the WHOLE point of standardization .. i don't think its that
Reiser4's EAs offer any more or less capabilities
On Wed, Jun 22, 2005 at 08:39:01PM -0700, Hans Reiser wrote:
Correct me if I am wrong:
What exists currently in VFS are vector instances, not classes. Plugins,
selected by pluginids, are vector classes, with each pluginid selecting
a vector class. You propose to have the vector class layer
On Wed, Jun 22, 2005 at 02:46:44AM -0500, David Masover wrote:
There's been sloppy code in the kernel before. I remember one bit in
particular which was commented Fuck me gently with a chainsaw. If I
remember correctly, this had all of the PCI ids and the names and
manufacturers of the
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 wanted, even if it was ugly. The philosophy
would be: choose a
Christoph Hellwig wrote:
I'm a bit confused about what you're saying here. What does the 'vector'
in all these expressions mean?
In OO terminology our *_operation structures are interfaces. Each particular
instance of such a struct that is filled with function pointers is a class.
Each
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christoph Hellwig wrote:
On Wed, Jun 22, 2005 at 02:46:44AM -0500, David Masover wrote:
There's been sloppy code in the kernel before. I remember one bit in
particular which was commented Fuck me gently with a chainsaw. If I
remember correctly,
On Gwe, 2005-06-24 at 20:21, Hans Reiser wrote:
Alan, this is FUD. Our V3 fsck was written after everything else was,
for lack of staffing reasons (why write an fsck before you have an FS
worth using). As a result, there was a long period where the fsck code
was unstable. It is reliable
On Sad, 2005-06-25 at 04:14, David Masover wrote:
Right, but even if I was a door geek, changing hinges costs more than
changing code. Now, if I were building a new house and I happened to
Probably not, programmers are expensive 8)
DVDs are cheap nowdays:
On Sun, Jun 26, 2005 at 12:21:52PM -0500, David Masover wrote:
I seem to remember the comment was more about hardcoded ID tables.
And this was the generic ID code database, which is now maintained out
of the kernel:
/usr/share/misc/pci.ids
A list of all known PCI ID's (vendors,
On Sun, 26 Jun 2005, Alan Cox wrote:
On Gwe, 2005-06-24 at 20:21, Hans Reiser wrote:
Alan, this is FUD. Our V3 fsck was written after everything else was,
for lack of staffing reasons (why write an fsck before you have an FS
worth using). As a result, there was a long period where the fsck
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christoph Hellwig wrote:
On Sun, Jun 26, 2005 at 12:21:52PM -0500, David Masover wrote:
I seem to remember the comment was more about hardcoded ID tables.
And this was the generic ID code database, which is now maintained out
of the kernel:
On Sun, 26 Jun 2005 02:48:06 CDT, David Masover said:
Lincoln Dale wrote:
this is the WHOLE point of standardization .. i don't think its that
Reiser4's EAs offer any more or less capabilities than standard EAs -
They do. Reiser4's EAs can look like any other object -- files,
folders,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
On Sun, 26 Jun 2005 02:48:06 CDT, David Masover said:
Lincoln Dale wrote:
this is the WHOLE point of standardization .. i don't think its that
Reiser4's EAs offer any more or less capabilities than standard EAs -
On Sun, 26 Jun 2005 14:58:07 CDT, David Masover said:
Plugins is a bad word. This user's combination of plugins is most
likely identical to other users', it's just which ones are enabled, and
which aren't? If they are all included, I assume they play nice.
Which ones are enabled. Exactly.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
On Sun, 26 Jun 2005 14:58:07 CDT, David Masover said:
Plugins is a bad word. This user's combination of plugins is most
likely identical to other users', it's just which ones are enabled, and
which aren't? If they are
[EMAIL PROTECTED] wrote:
(Hint - work out how long a kernel 'make' would take
if you were doing it inside a .tar.bz2).
After the first time, not very long, if you had enough ram the
plugin would keep the data uncompressed until it flushed it to disk.
Performance might even improve
Christoph Hellwig wrote:
On Wed, Jun 22, 2005 at 08:39:01PM -0700, Hans Reiser wrote:
Correct me if I am wrong:
What exists currently in VFS are vector instances, not classes. Plugins,
selected by pluginids, are vector classes, with each pluginid selecting
a vector class. You propose to have
David Masover wrote:
[EMAIL PROTECTED] wrote:
On Sun, 26 Jun 2005 14:58:07 CDT, David Masover said:
Plugins is a bad word. This user's combination of plugins is most
likely identical to other users', it's just which ones are enabled, and
which aren't? If they are all included, I assume
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Reiser wrote:
David Masover wrote:
[EMAIL PROTECTED] wrote:
On Sun, 26 Jun 2005 14:58:07 CDT, David Masover said:
Plugins is a bad word. This user's combination of plugins is most
likely identical to other users', it's just which ones
On Sun, 26 Jun 2005 19:16:48 CDT, David Masover said:
But, to avoid confusion, the inclusion of a crytocompress plugin in a
given kernel doesn't mean that all files accessed from that kernel are
encrypted and compressed. It just means that you can pick an individual
file and set it to be
On Sun, 26 Jun 2005 17:35:48 CDT, David Masover said:
Right. So please explain what crypto/raw/foo and crypto/inflated/foo.gz
give you.
In that example (shouldn't have used the name crypto, but oh well), it
should be crypto/raw/foo.gz and crypto/inflated/foo -- where foo.gz is
the
On Sun, 26 Jun 2005 15:54:25 PDT, Hans Reiser said:
[EMAIL PROTECTED] wrote:
(Hint - work out how long a kernel 'make' would take
if you were doing it inside a .tar.bz2).
After the first time, not very long, if you had enough ram the
plugin would keep the data uncompressed until
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
On Sun, 26 Jun 2005 17:35:48 CDT, David Masover said:
Right. So please explain what crypto/raw/foo and crypto/inflated/foo.gz give
you.
In that example (shouldn't have used the name crypto, but oh well), it
should be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
On Sun, 26 Jun 2005 17:35:48 CDT, David Masover said:
Right. So please explain what crypto/raw/foo and crypto/inflated/foo.gz give
you.
In that example (shouldn't have used the name crypto, but oh well), it
should be
701 - 800 of 1292 matches
Mail list logo
