Ric Wheeler wrote:
David Masover wrote:
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
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
David Masover wrote:
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
David Masover wrote:
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
there can be more than one flush thread per file does not
mean it is likely there will be.
CPU scheduling of compression/decompression is an area that could use
work in the future.For now, just understand that what we do is
better than doing nothing.;-/
Edward.
lg Clemens
2006/8/30, Hans Reiser
Xuân Baldauf wrote:
Hello,
I created backup DVDs formatted using reiserfs. However, mounting them
is not possible. If I try to mount such a DVD, I get following results:
Aug 31 01:08:18 notebook2 kernel: ReiserFS: hdc: using ordered data mode
Aug 31 01:08:18 notebook2 kernel: ReiserFS: hdc:
Is it already sent in? If not, can it go out today?
Hans
Alexander Zarochentsev wrote:
Hello,
On 30 August 2006 01:10, Andrew James Wade wrote:
Hello Alexander,
In addition to your patch, I've also applied the patch below. With
these two patches the fs is much more stable for me.
Edward Shishkin wrote:
(Plain) file is considered as a set of logical clusters (64K by
default). Minimal unit occupied in memory by (plain) file is one
page. Compressed logical cluster is stored on disk in so-called
disk clusters. Disk cluster is a set of special items (aka ctails,
or
PFC wrote:
I made a little benchmark on my own PC (Athlon64 3200+ in 64 bit
gentoo)
http://peufeu.free.fr/compression.html
So, gzip could be used on PCs having very fast processors and very
slow harddrives, like Core Duo laptops.
However, lzo compresses nearly as much and is
PFC, thanks for giving us some real data. May I post it to the lkml thread?
In essence, LZO wins the benchmarks, and the code is hard to read. I
guess I have to go with LZO, and encourage people to take a stab at
dethroning it.
Hans
PFC wrote:
I have made a little openoffice spreadsheet
Thanks. Did you run an older version of reiser4 before this? If yes,
then this may have been fixed but only showed up for you now. Zam?
Hans
Posern wrote:
Hi.
I don't know if this can help you to improve reiser4:
On a:
Linux jolie 2.6.17.8-reiser4-r3-jolie #1 Tue Aug 15 00:14:45 CEST
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-40% slower than
zam, please review this unless vs is back.
What is the file size? Is there anything special about the file (holes,
etc.)?
Thanks for finding what I assume is a bug. (I wonder if this has been
sporadically affecting use of reiser4 with bootloaders.)
Hans
Brice Arnould wrote:
Hi
Two
Alexey Dobriyan wrote:
Reiser4 developers, Andrew,
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.
Hmm. LZO is the best compression algorithm for the task as
Nigel Cunningham wrote:
For Suspend2, we ended up converting the LZF support to a cryptoapi
plugin. Is there any chance that you could use cryptoapi modules? We
could then have a hope of sharing the support
It is in principle a good idea, and I hope we will be able to say yes.
However, I have
I am very sorry to inform you that our fsck guy is on vacation, and we
have no effective backup for him.
Hans
Brian Davis wrote:
Hello,
I've paid the 25 dollars, but I haven't gotten a response yet so I'm
trying this list
I have a disk which has a single partition with reiserfs version
Namesys wrote the Reiser4 filesystem.
We are looking for persons who need any kind of kernel hacking or
storage system code done.
We have a complete team of kernel programmers available. Do you have
race conditions you need found, spaghetti code from a predecessor that
nobody can do anything
Jeff Mahoney wrote:
Also, I think the bigalloc behavior just ultimately ends up introducing
even more fragmentation on an already fragmented file system. It'll keep
contiguous chunks together, but those chunks can end up being spread all
over the disk.
-Jeff
Yes, and almost as important,
Thanks Andrew, please be patient and persistent with us at this time, as
one programmer is on vacation, and the other is only able to work a few
hours a day due to an illness.
Hans
He indicated that he would threaten to include reiser4 in 2.6.19 once we
got our fixes back to him (as a way of getting more comments), and that
it would most likely go in in 2.6.20 as a result. I told him that most
of the team was on vacation or sick, so we would probably be delayed in
getting
Ric Wheeler wrote:
Hans Reiser wrote:
I am skeptical that bitflip errors above the storage layer are as common
as the ZFS authors say, and their statistics that I have seen somehow
lack a lot of detail about how they were gathered. If, say, a device
with 100 errors counts as 100 instances
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 true,
because we
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
between layers for
David Masover wrote:
that's 3-7% fragmentation.
which is high enough to hurt performance. 50mb/s * 0.01 seconds =
amount of transfer a seek costs. He needs a repacker. After we resolve
code review issues from akpm.
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
I am skeptical that bitflip errors above the storage layer are as common
as the ZFS authors say, and their statistics that I have seen somehow
lack a lot of detail about how they were gathered. If, say, a device
with 100 errors counts as 100 instances for their statistics. Well,
it would be
Bernd Schubert wrote:
An alternative might be a reiser4 fuse port.
Fuse is not performance effective.
Bruce, I read your article on Linus and GPL V3, and I understand that
you are frustrated by his not going for V3. I suspect the main thing
that sparked your concern in writing the article about reiser4 is that I
am somehow doing something different that affects licensing, and not
conforming on
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.
Edward Shishkin wrote:
Hans Reiser wrote:
Edward Shishkin wrote:
How about we switch to ecc, which would help with bit rot not sector
loss?
Interesting aspect.
Yes, we can implement ECC as a special crypto transform that inflates
data. As I mentioned earlier, it is possible via
Pavel Machek wrote:
On Wed 2006-08-09 02:37:45, 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.
Yes, you
Bruce Byfield wrote:
Wow. I thought only the judiciary insulated itself from ever learning
of its mistakes that well.:-/
Oh, we have ways of learning. As witness this email exchange :)
You are right, it is only the judiciary.;-)
TongKe Xue wrote:
A really stupid question ... why not put Reiser4 in one of the BSDs?
The cost to port to BSD is about $500k, and I am not possessed of a lot
of money at this time. There is also a license issue, I don't want
reiser4 to be BSD licensed, people who want proprietary additions to
Bruce, regarding a longstanding convention of avoiding plugins in the
kernel, considering that we are the first and only ones ever to have
plugins, and considering the existence of binary kernel modules, I don't
think your characterization is accurate. Perhaps there was some
licensing controversy
Jorgen Hermanrud Fjeld wrote:
The recent discussions regarding reiser4 and possible inclusion have
also caught the eye(s) of LWN.
I have made the article available for you, non-lwn-subscribers, so that you may
have a look at it here
http://lwn.net/SubscriberLink/193663/9d2ac03195c775bc/;.
Edward Shishkin wrote:
How about we switch to ecc, which would help with bit rot not sector
loss?
Interesting aspect.
Yes, we can implement ECC as a special crypto transform that inflates
data. As I mentioned earlier, it is possible via translation of key
offsets with scale factor 1.
Antonio Vargas wrote:
On 8/4/06, Edward Shishkin [EMAIL PROTECTED] wrote:
Hans Reiser wrote:
Edward Shishkin wrote:
Matthias Andree wrote:
On Tue, 01 Aug 2006, Hans Reiser wrote:
You will want to try our compression plugin, it has an ecc for every
64k
What kind
Marcel Hilzinger wrote:
Am Donnerstag, 3. August 2006 10:55 schrieb Marcel Hilzinger:
Am Dienstag, 1. August 2006 23:59 schrieb Sander Sweers:
On Tue, 2006-08-01 at 23:12 +0200, Maciej Sołtysiak wrote:
[...]
Are there any on the list who know of rpm's for
Edward Shishkin wrote:
Matthias Andree wrote:
On Tue, 01 Aug 2006, Hans Reiser wrote:
You will want to try our compression plugin, it has an ecc for every
64k
What kind of forward error correction would that be,
Actually we use checksums, not ECC. If checksum is wrong, then run
Sander Sweers wrote:
With the approval of Namesys I would like to add a new entry to the wiki
frontpage.
It would be very appreciated.
Andrew Morton wrote:
On Mon, 31 Jul 2006 10:26:55 +0100
Denis Vlasenko [EMAIL PROTECTED] wrote:
The reiser4 thread seem to be longer than usual.
Meanwhile here's poor old me trying to find another four hours to finish
reviewing the thing.
Thanks Andrew.
The writeout code is ugly,
Matthias Andree wrote:
Have you ever seen VxFS or WAFL in action?
No I haven't. As long as they are commercial, it's not likely that I
will.
WAFL was well done. It has several innovations that I admire,
including quota trees, non-support of fragments for performance reasons,
and the
Theodore Tso wrote:
On Mon, Jul 31, 2006 at 09:41:02PM -0700, David Lang wrote:
just becouse you have redundancy doesn't mean that your data is idle enough
for you to run a repacker with your spare cycles. to run a repacker you
need a time when the chunk of the filesystem that you are
Alan, I have seen only anecdotal evidence against reiserfsck, and I have
seen formal tests from Vitaly (which it seems a user has replicated)
where our fsck did better than ext3s. Note that these tests are of the
latest fsck from us: I am sure everyone understands that it takes time
for an fsck
Ric Wheeler wrote:
Alan Cox wrote:
You do it turns out. Its becoming an issue more and more that the sheer
amount of storage means that the undetected error rate from disks,
hosts, memory, cables and everything else is rising.
I agree with Alan
You will want to try our compression
Gregory Maxwell wrote:
This is why ZFS offers block checksums... it can then try all the
permutations of raid regens to find a solution which gives the right
checksum.
ZFS performance is pretty bad in the only benchmark I have seen of it.
Does anyone have serious benchmarks of it? I suspect
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. That none of the shy developers working for me
actively post on lkml hurts us quite a bit.
It might even be socially effective to shut
David Masover wrote:
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
Jesper Juhl wrote:
Thanks. That's a nice little test suite.
Yes, it is quite useful, our developers have added it to the regression
suite
Hans
Jesper Juhl wrote:
On 30/07/06, Hans Reiser [EMAIL PROTECTED] wrote:
Jesper Juhl wrote:
Thanks. That's a nice little test suite.
Yes, it is quite useful, our developers have added it to the regression
suite
That's nice.
Now how about that lock validator message I managed
Maciej Sołtysiak wrote:
Hmm, what about linspire / freespire ? Linsire is a proud reiser4 debugging
sponsor as the website (http://www.namesys.com) says.
Wouldn't they want to include reiser4 in their distro first?
Not if the mainstream kernel is not going to add it.
Hans
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 interest in using
Jeff Garzik wrote:
Using guilt as an argument in a technical discussion is a flashing red
sign that says I have no technical rebuttal
Wow, that is really nervy. Let's recap this all:
* reiser4 has a 2x performance advantage over the next fastest FS
(ext3), and when compression ships in a
Mike and Lukasz, please post your email to not just reiserfs-list, where
only the reiserfs team will read it, but also to lkml if you could,
please? Thanks for your support, user opinions count for a lot on lkml.
Nikita Danilov wrote:
Hans Reiser writes:
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
Jeff Garzik wrote:
Actually, there is reiser4 brokenness lurking in Hans' statement, too:
Where! Someone tell me!;-)
A filesystem WITH plugins must still handle the standard Linux
compatibility stuff that other filesystems handle.
Hmm, you mean we should first implement regular unix file
Matthias Andree wrote:
I wonder what makes the hash overflow issue so complicated (other than
differing business plans, that is) that upgrading in place isn't
possible. Changes introduce instability, but namesys were proud of their
regression testing - so how sustainable is their internal test
Linus Torvalds wrote:
In other words, if a filesystem wants to do something fancy, it needs to
do so WITH THE VFS LAYER, not as some plugin architecture of its own.
Where does VFS store the plugin ids that specify per file variations?
/etc/fstab? Also, is (current) VFS the interface for
Let me put it from my perspective and stop pretending to be unbiased, so
others can see where I am coming from. No one was interested in our
plugins. We put the design on a website, spoke at conferences, no one
but users were interested. No one would have conceived of having
plugins if not for
Hua Zhong wrote:
I remember someone said something along the lines of Linux is evolution, not
revolution. To me it seems unreasonable to put all
the revolutionary VFS burden upon reiserfs team. It's not practical.
Thanks for saying that Hua. We have a guy named Nate Diller, who
probably
David Masover wrote:
Although I should mention, Hans, that there is a really good reason to
prefer the 15 minute patches. The patches that take a week are much
harder to read during that week than any number of 15 minute incremental
patches, because the incremental patches are already broken
David Masover wrote:
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 running on a Reiser4
root right now...
I think you get to be the one to tell
David Masover wrote:
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
It crashed on me, and needed an fsck. At least our fsck works well
though:-/, Vitaly, you did a great job of making the user interface
informative.
Hans
Matthias Andree wrote:
The father declared his child unsupported,
I never did that.
and that's the end
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
Thanks Christian. You can go ahead and add something to our wiki
pointing to it if you would like. This might help tide people over
until the repacker ships.
Hans
Maciej Sołtysiak wrote:
Hello Hans,
Saturday, July 22, 2006, 8:03:28 PM, you wrote:
We are going to give changing the paradigm a try. The difference
between 4.1-beta and 4.0 is that different plugins are the default, and
the experimental code is in the plugins you see when mounting with
Mike Benoit wrote:
On Sat, 2006-07-22 at 07:34 -0500, David Masover wrote:
The compression will probably mostly be about speed. Remember, if
we're
talking about people who want to see tangible, visceral results,
we're
probably also talking about end-users. And trust me, the vast
majority
I am going to do the enhanced semantics first, so that somebody does not
beat me to it.
David's examples are good.
There's another note to kernel developers -- if Reiser5, 6, and 7 are
implemented as suites of plugins on top of Reiser4, then the Reiser4
code will be maintained for a very
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
neglected. This is true even if line for line the 1 week to read patch
is more valuable.
Jeff Mahoney wrote:
That particular bug isn't in the bitmap scanning code, it's a side
effect of the write batching higher up.
Did you write the code that looks for a window of 32
blocks? If not, and if this code has been around for a long time, I
apologize. I thought you did write it and
Jeff Mahoney wrote:
Anyone up for it? :) There are changes I'd like to see in reiser3,
particularly ones that address the severe problems observed in David
Chinner's high bandwidth file system talk this year at OLS. Specifically,
it ended up making very little progress and spending the
Matt Heler wrote:
On Sunday 23 July 2006 12:20 am, Hans Reiser wrote:
The way you wrote this, makes it sound like a userspace issue, and _not_ a
problem with reiserfs.
It was a problem with reiserfs. Code was added to search for the
perfect spot to fit a file. If there is no perfect
David Masover wrote:
And it's not just databases. Consider BitTorrent. The usual
BitTorrent way of doing things is to create a sparse file, then fill
it in randomly as you receive data. Only if you decide to allocate
the whole file right away, instead of making it sparse, you gain
Nate Diller wrote:
On 7/21/06, Mike Benoit [EMAIL PROTECTED] wrote:
Has the Reiser4 team looked at utilizing the OSDL Scalable Test Platform
(STP) service to benchmark and test Reiser4 patches? They seem to offer
a wide variety of hardware to test on, and already have some file system
We are going to give changing the paradigm a try. The difference
between 4.1-beta and 4.0 is that different plugins are the default, and
the experimental code is in the plugins you see when mounting with the
mount option 4.1-beta. Let's see if it works in practice.
Hans
Pysiak Satriani
vs will try to help you Did Jeff fix the mythtv performance problem
yet? If not, vs, please rip out the optimization which goes looking
for the perfect length spot for files, and send both joel and akpm the
patch. It is really not such a bad algorithm to just use the spots that
are free in
David Masover wrote:
Hans Reiser wrote:
On a more positive note, Reiser4.1 is getting closer to release
Good news! But it's been awhile since I've followed development, and
the homepage seems out of date (as usual). Where can I find a list of
changes since v4?
By out of date, I
Elena, on Monday can you comment on this in detail?
Thanks,
Hans
Mike Benoit wrote:
Has the Reiser4 team looked at utilizing the OSDL Scalable Test Platform
(STP) service to benchmark and test Reiser4 patches? They seem to offer
a wide variety of hardware to test on, and already have some file
David Masover wrote:
Disclaimer: I don't speak for Namesys, and I don't work here. While
I'm pretty confident I understand their vision, the final word on
anything Reiser is always from Hans Reiser.
David described my views pretty well, and saved me much typing.:)
Mike Benoit wrote:
On top of that, I don't see how a repacker would help these work loads
much as the files usually have a high churn rate.
I think Reiserfs is used on a lot more than squid servers. For them,
80% of files don't move for long periods of time is the usual industry
statistic
David Masover wrote:
Andreas Schäfer wrote:
Don't get too excited -- the transactions probably aren't done yet.
Without those, no filesystem that claims to journal data is really
any better than a filesystem which only journals metadata. Even
once they are implemented (or even if they are
Pysiak Satriani wrote:
Hello,
suppose pseudo files, file-as-directory are on my r4 partition and are usuable.
Does namesys' vision allow things like storing image thumbnails inside the
file
itself ?
Example using jpgtn (jpgtn creates thumbnails of jpg files)
// create 150px thumbnail
$ jpgtn
Well, it seems we still aren't quite as stable as we were 6 months ago
(the new reduced cpu usage code was extensive, as was the VFS change
code), and we know of a bug we can reproduce using our standard tests.
Also, it seems we can oops when a particular program is run to consume
all memory
Payal Rathod wrote:
Hi,
I was just reading about filesystems and my ideas are a bit confused.
I read quite a few articles on net but still my basic doubts are not
completely clarified. I thought this would be the right place to ask, since
many
journalling gurus might be here.
Can someone tell
It contains 5 bug fixes. If testing goes well we will release it
tomorrow.It is listed below in case you feel like helping to test,
it works on vs's workstation
ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.17/reiser4-for-2.6.17-1.patch.gz
Apologies to our users that this took a
Jeffrey Mahoney wrote:
Hans Reiser wrote:
Jeffrey Mahoney wrote:
This is not
the desired interpretation, which is why we need to replace the pathname
separator in the name. ReiserFS is the component that is choosing to use
the block device name as a pathname component and is responsible
Jeff Mahoney wrote:
Hans Reiser wrote:
I don't understand your patch and cannot support it as it is written.
Perhaps you can call me and explain it on the phone.
I seriously can't tell if you're deliberately trying to be difficult or
not. It's a simple replace / with ! before sending
Jeff Mahoney wrote:
As stated before numerous times by both Andrew and myself, the correct
solution is to eliminate / from block device names.
Why? It is elegant to have those /'s Just create the directory,
how is that hard?
This patch was a
band-aid until that's done.
-Jeff
--
[EMAIL PROTECTED] wrote:
On Sun, 16 Jul 2006 20:02:27 PDT, Hans Reiser said:
Create a mountpoint which knows how to resolve a/b without using a
directory.
And said mountpoint gets past the '/' interpretation in the VFS, how, exactly?
fs/namei.c, do_path_lookup() does magic
Jeff Mahoney wrote:
[EMAIL PROTECTED] wrote:
On Sun, 16 Jul 2006 20:02:27 PDT, Hans Reiser said:
Create a mountpoint which knows how to resolve a/b without using a
directory.
And said mountpoint gets past the '/' interpretation in the VFS, how,
exactly?
fs/namei.c, do_path_lookup
Jeff Mahoney wrote:
Hans Reiser wrote:
Jeff Mahoney wrote:
Hans Reiser wrote:
I don't understand your patch and cannot support it as it is written.
Perhaps you can call me and explain it on the phone.
I seriously can't tell if you're deliberately trying to be difficult or
not. It's
It seems like bad memory is growing as a percentage of user filesystem
problem sources. Do others have that feeling also?
Hans
Brad Dameron wrote:
On Mon, 2006-07-17 at 21:55 +0400, Vladimir V. Saveliev wrote:
Hello
On Mon, 2006-07-17 at 10:53 +0200, Francisco Javier Cabello wrote:
Jeff Mahoney wrote:
Hans Reiser wrote:
Jeff Mahoney wrote:
1) Because then the behavior of /proc/fs/reiserfs/ would be
inconsistent. Devices that contain slashes end up being one level deeper
than other devices, which is silly and a userspace visible change.
And you think translating
So the Plan 9 and Unix way would be to let the driver parse the number
part of the name after the last slash. What I don't understand is why
reiserfs is getting involved here, rather than recognizing the driver as
an extension of the namespace, seeing the driver as a mountpoint, and
just passing
Jindrich Makovicka wrote:
On Fri, 14 Jul 2006 00:01:49 -0700
Hans Reiser [EMAIL PROTECTED] wrote:
rvalles wrote:
I believe those two are related. I'm having the pauses (of many
minutes at times!) when writing to reiser4. It seems it is triggered
mostly by the use of fsync(); NFS in sync
Ryan Steffes wrote:
On 7/14/06, *Michael T. Dean* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
On 07/14/2006 09:31 PM, Carl Fongheiser wrote:
On 7/14/06, *Ryan Steffes* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
. Is this related to the difference between BSD's namei and
Linux's? BSD is the one getting it right.
Hans
Jeffrey Mahoney wrote:
Hans Reiser wrote:
So the Plan 9 and Unix way would be to let the driver parse the number
part of the name after the last slash. What I don't understand is why
Jeff Mahoney wrote:
Hans Reiser wrote:
Hans, we're all in agreement that we'd prefer drivers not use names with
slashes in them,
there is nothing wrong with using names that have slashes. The thing
that is wrong is somehow needing to translate them into names with !'s.
and it would
Jeffrey Mahoney wrote:
Hans Reiser wrote:
Jeff Mahoney wrote:
Hans Reiser wrote:
Hans, we're all in agreement that we'd prefer drivers not use names with
slashes in them,
there is nothing wrong with using names that have slashes. The thing
that is wrong is somehow needing
1 - 100 of 1054 matches
Mail list logo
