idder ignoring the restriction when
running with "-a" or when running as root - that would reduce or
eliminate the problems with the transition.
However, if this is implemented in mount itself, it is totally
orthogonal to the FUSE merge discussion.
--
Ragnar Kjørstad
Software Engineer
Scali - ht
, if this is implemented in mount itself, it is totally
orthogonal to the FUSE merge discussion.
--
Ragnar Kjørstad
Software Engineer
Scali - http://www.scali.com
Scaling the Linux Datacenter
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
)
E.g, wouldn't a aio_stat() allow simular or better speedups in a way
that doesn't depend on ext2/3 internals?
I bet it would make a significant difference from things like "ls -l" in
large uncached directories and imap-servers with maildir?
--
Ragnar Kjørstad
Software Eng
On Thu, Jul 19, 2001 at 07:38:15PM -0500, Tad Dolphay wrote:
> I know there was a fix for a "Busy inodes after unmount" problem in
> 2.4.6-pre3. Here's an excerpt from a posting to the NFS mailing list
> from Neil Brown:
Thanks. I'll try that and see if that solves the problem (also the XFS
UUID
On Thu, Jul 19, 2001 at 04:22:07PM -0400, Christian, Chip wrote:
> I found the same thing happening. Tracked it down in our case to using fdisk to
>re-read disk size before mounting. Replaced it with "blockdev --readpt" and the
>problem seems to have gone away. YMMV.
I've now been able to
On Thu, Jul 19, 2001 at 04:22:07PM -0400, Christian, Chip wrote:
I found the same thing happening. Tracked it down in our case to using fdisk to
re-read disk size before mounting. Replaced it with blockdev --readpt and the
problem seems to have gone away. YMMV.
I've now been able to
On Thu, Jul 19, 2001 at 07:38:15PM -0500, Tad Dolphay wrote:
I know there was a fix for a Busy inodes after unmount problem in
2.4.6-pre3. Here's an excerpt from a posting to the NFS mailing list
from Neil Brown:
Thanks. I'll try that and see if that solves the problem (also the XFS
UUID
ce code. I am not pretty sure where is the location of
> the source code related to the above operations. Like, can you tell me the
> location of the linux kernel source code to answer an ARP request packet,
> to build a hash function to filter the incoming IP packets before it
> enters
a hash function to filter the incoming IP packets before it
enters the TCP/IP stack?
--
Ragnar Kjørstad
Big Storage
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
obably relink your deleted files. Read the
man-page and back up your partition first.
You can find reiserfsprogs-3.x.0j.tar.gz at ftp.namesys.com.
--
Ragnar Kjørstad
Big Storage
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PR
files. Read the
man-page and back up your partition first.
You can find reiserfsprogs-3.x.0j.tar.gz at ftp.namesys.com.
--
Ragnar Kjørstad
Big Storage
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
> That's a wonderful reason to put it _not_ into superblock... OK, what's
> wrong with the variant above?
The information will not be available without mounting the filesystem
first.
However - the LVM way sounded much better, so this may not matter.
--
Ragnar Kjørstad
Big Storage
-
To
On Wed, Mar 14, 2001 at 02:32:21PM -0500, Alexander Viro wrote:
Sorry - .last.mounted in the root of filesystem, indeed.
The writing side can't be done in userland without basically making
mount(8) know about the superblock layout of each and every filesystem:
That's a wonderful reason
On Fri, Sep 22, 2000 at 03:23:26PM -0700, Hans Reiser wrote:
> I think Xuan's algorithm is good, so I want to add to it.:-)
>
> Ragnar, I don't understand your objection to it. It is always the
> case that if you specify real
> time constraints that are impossible then they aren't met.
My
dn't include priorities. I now think this can be
fixed by having different ideas for "full" queues according to the
priority of the process.
This way you don't need one index by time and one by sector.
--
Ragnar Kjørstad
Big Storage
-
To unsubscribe from this list: send the l
On Fri, Sep 22, 2000 at 03:23:26PM -0700, Hans Reiser wrote:
I think Xuan's algorithm is good, so I want to add to it.:-)
Ragnar, I don't understand your objection to it. It is always the
case that if you specify real
time constraints that are impossible then they aren't met.
My
# request-nr
looks much better, doesn't it?
But then again, maybe I just didn't understand how the current code
works... I'm going to shut up now..
--
Ragnar Kjørstad
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
sector 16 is added:
Current queue (full)
06:09:15 # sector to be written to
04:00:01 # request-nr
Second queue:
02:03:16 # sector to be written to
07:06:08 # request-nr
looks much better, doesn't it?
But then again, maybe I just didn't understand how the current code
works... I'm going to shut u
On Wed, Sep 13, 2000 at 08:08:12PM -0300, Rik van Riel wrote:
> On Thu, 14 Sep 2000, Ragnar Kjørstad wrote:
> > On Wed, Sep 13, 2000 at 06:57:21PM -0300, Rik van Riel wrote:
> > > > Another potentially stupid question:
> > > > When the queue gets too lon
with the twist that we /do/ allow merges on the queue
> that's being processed by the disk, but no insertions of new
> requests)
I don't think you should allow merges. If one process is doing a big
IO operation on a big file it would still get _all_ capacity, right?
--
Ragnar Kjørstad
-
To
This way the higher is the block number, more likely that
> rq will wait a lot.
If a new request is made for a sector before the current sector (the
sector of the last request to be served), the new request should be
added to the second queue even if the first one is not too old.
--
Ragna
and thus performance overhead, right?
If you, however have a simple rule that max 100 requests should be put
in each queue, it's easy to know when to start a new one. The number 100
should be found by calculating how many requests can be served within
the acceptable latency.
--
Ragnar
performance overhead, right?
If you, however have a simple rule that max 100 requests should be put
in each queue, it's easy to know when to start a new one. The number 100
should be found by calculating how many requests can be served within
the acceptable latency.
--
Ragnar Kjørstad
-
To unsubscribe
that
rq will wait a lot.
If a new request is made for a sector before the current sector (the
sector of the last request to be served), the new request should be
added to the second queue even if the first one is not too old.
--
Ragnar Kjørstad
-
To unsubscribe from this list: send the line
On Wed, Sep 13, 2000 at 08:08:12PM -0300, Rik van Riel wrote:
On Thu, 14 Sep 2000, Ragnar Kjørstad wrote:
On Wed, Sep 13, 2000 at 06:57:21PM -0300, Rik van Riel wrote:
Another potentially stupid question:
When the queue gets too long/old, new requests should be put in
a new queue
25 matches
Mail list logo
