headers
Trond Myklebust | 1 Apr 2006 06:30
Picon
Picon

Re: [PATCH 2/4] locks: don't unnecessarily fail posix lock operations

On Fri, 2006-03-31 at 21:46 +0200, Miklos Szeredi wrote:
> > > In the first case no new locks are needed.  In the second, no locks
> > > are modified prior to the check.
> > 
> > Consider something like
> > 
> > fcntl(SETLK, 0, 100)
> > fcntl(SETLK, 0, 100)
> > fcntl(SETLK, 0, 100)
> 
> Huh?  What is the type of lock in each case.
> 
> But anyway your example is no good.  If the new lock completely covers
> the previous one, then the old lock will simply be adjusted and no new
> lock is inserted.

Slip of the mailer. It posted when I wanted to cancel the mail (I had to
step out for an errand)...

OK. I see what you mean now. Do you agree with the following analysis?

        1) We need 2 extra locks for the case where we
        upgrade/downgrade, a single existing lock and end up splitting
        it.

        2) We need to use 1 extra lock in the case where we unlock and
        split a single existing lock.

        3) We also need to use 1 extra lock in the case where there is
        no existing lock that is contiguous with the region to lock.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Miklos Szeredi | 1 Apr 2006 08:39
Picon

Re: [PATCH 2/4] locks: don't unnecessarily fail posix lock operations

> OK. I see what you mean now. Do you agree with the following analysis?
> 
>         1) We need 2 extra locks for the case where we
>         upgrade/downgrade, a single existing lock and end up splitting
>         it.
> 
>         2) We need to use 1 extra lock in the case where we unlock and
>         split a single existing lock.
> 
>         3) We also need to use 1 extra lock in the case where there is
>         no existing lock that is contiguous with the region to lock.

   4) Also 1 extra lock needed if there's an existing lock that is
      contiguous/overlapping with the new region but it's a different
      type, and no existing locks are completely covered

> In all other cases, we resort to modifying existing locks instead of
> using new_fl/new_fl2.
> 
> In cases (1) and (2) we do need to modify the existing lock. Since this
> is only done after we've set up the extra locks, we're safe.

And 4.

> Could I still suggest a couple of modifications to your patch? Firstly,
> we only need to test for 'added' once.

Like this?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nathan Scott | 1 Apr 2006 08:50
Picon
Favicon

Re: [RFC][PATCH 0/2]Extend ext3 filesystem limit from 8TB to 16TB

Hi Andi,

On Fri, Mar 31, 2006 at 03:33:24PM +0200, Andi Kleen wrote:
> Mingming Cao <cmm <at> us.ibm.com> writes:
> > > Have you done tests _near_ 8TB with a 32-bit machine, even without these
> > > patches?
> > No I haven't. The >8TB right now is attached to a 64 bit machine, but we
> > should able to move it to a 32 bit machine.
> 
> If you use XFS or JFS as backing fs you can use a holey loop device
> to simulate it.  When I tried this last time JFS worked better for me.
> XFS doesn't seem to like that many extents as will be created by 
> mkfs.ext2.

Mainline has this issue resolved now (very recently, post-.16).

This (loopback on a local file) technique will get you up to 16TB
for 32 bit platforms, where you hit the unsigned long page->index
limit (but sounds like thats fine for the testing you're doing).

A related technique we've used in the past in testing XFS on large
devices (we've successfully tested in petabyte ranges using this,
on 64 bit systems of course) is to write a tool that modifies the
values in the ondisk data structures managing the "lower" areas of
the device to say "all the space here is used", which then forces
new allocations to be done in the "higher" parts of the device
address space.  Testing then follows this recipe: mkfs-on-loop,
then run the tool, then mount, then run the usual test suites ...
perhaps thats useful here too (I dunno if the ext2/3 format lends
itself to that or not).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Van Brandon | 1 Apr 2006 23:07
Picon
Favicon

It's Here Now 9haz2


Obtain a prosperous future, money-earning power and
the prestige that comes with having the career position you've
always dreamed of. Diplomas from prestigious non-accredited
universities based on your present knowledge and life experience.

No required tests, classes, books or examinations.

Bachelors', Masters', MBA's, Doctorate & Ph.D. degrees
available in your field.

Confidentiality Assured..

Call Now To Receive Your Diploma Within 2 Weeks

1-484-693-8861

Y2
-
To unsubscribe from this list: send the line "unsubscribe linux-assembly" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
UZAIR LAKHANI | 2 Apr 2006 11:32
Picon
Favicon

Overhead of Using a Stackable File System(Wrapfs)

Hello All,

I want to enquire about the percent overhead involved
when we use Wrapfs(null layer stacking file system)
over ext3.

I want to enquire this because I want to use Wrapfs in
a network environment and there will be an additional
overhead of network communication.

Thanks,
Uzair Lakhani,
Karachi, Pakistan.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 5 comments |
headers
Avishay Traeger | 2 Apr 2006 20:07
Picon
Favicon

Re: Overhead of Using a Stackable File System(Wrapfs)

On Sun, 2006-04-02 at 01:32 -0800, UZAIR LAKHANI wrote:
> Hello All,
> 
> I want to enquire about the percent overhead involved
> when we use Wrapfs(null layer stacking file system)
> over ext3.

It should only be a few percent (if I remember correctly, less than 5),
but it would depend on your machine and workload.  If you want an exact
answer, just run some benchmarks on ext3 and wrapfs/ext3.

> I want to enquire this because I want to use Wrapfs in
> a network environment and there will be an additional
> overhead of network communication.

If you're still talking about implementing NFS using stackable file
systems, please note that we decided that was not a good idea.

Good luck.

Avishay Traeger
http://www.fsl.cs.sunysb.edu/~avishay/

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 3 comments |
headers
Mingming Cao | 2 Apr 2006 22:13
Picon
Favicon

Re: [RFC][PATCH 0/2]Extend ext3 filesystem limit from 8TB to 16TB

On Fri, 2006-03-31 at 14:42 -0800, Mingming Cao wrote: 
> On Wed, 2006-03-29 at 17:54 -0800, Andrew Morton wrote:
> > Mingming Cao <cmm <at> us.ibm.com> wrote:
> > >
> > > The things need to be done to complete this work is the issue with
> > >  current percpu counter, which could not handle u32 type count well. 
> > 
> > I'm surprised there's much of a problem here.  It is a 32-bit value, so it
> > should mainly be a matter of treating the return value from
> > percpu_counter_read() as unsigned long.
> > 
> > However a stickier problem is when dealing with a filesystem which has,
> > say, 0xffff_ff00 blocks.  Because percpu counters are approximate, and a
> > counter which really has a value of 0xffff_feee might return 0x00000123. 
> > What do we do then?
> > 
> 
> Hmm... I think we had this issue already even with today's 2**31 ext3.
> Since ext2/3 always use percpu_counter_read_positive() to get the total
> number of free blocks, so if the real free blocks is 0x0fff_feee, and
> the approximate value from the percpu counter is 0xf000_0123, the
> percpu_counter_read_positive() will return back 0x0000123.
> 

In fact, even worse, percpu_counter_read_positive() always return 1 if
the value is negative (>2**31). So this is not suitable for ext3's
2**32 block numbers. I think we should use percpu_counter_read() and
cast it to unsigned long for ext3's free blocks (and probably for free
inodes also).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Erez Zadok | 3 Apr 2006 18:27
Picon
Favicon

Re: Overhead of Using a Stackable File System(Wrapfs)

You can find a lot of papers spanning several years and covering a wide
variety of stackable file systems, with detailed performance evaluations,
here:

	http://www.filesystems.org/

Erez.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Andrew Morton | 4 Apr 2006 08:17

Fw: atyfb doesn't work for me


Begin forwarded message:

Date: 04 Apr 2006 01:18:44 -0400
From: Greg Stark <gsstark <at> mit.edu>
To: linux-kernel <linux-kernel <at> vger.kernel.org>
Subject: atyfb doesn't work for me

When I try to load atyfb I get messages about "unsupported xclk source" and
"vclk out of range" and the fb devices don't seem to be active. That is, 
  fbset -fb /dev/fb?
all say "no such device"

I see there are module parameters to override some of these settings but I'm
not clear where I would find the correct values to use. And surely the fb
driver ought to be able to come up usable values on its own?

[   25.724880] PCI: Enabling device 0000:02:0b.0 (0080 -> 0083)
[   25.724943] ACPI: PCI Interrupt 0000:02:0b.0[A] -> GSI 23 (level, low) -> IRQ 18
[   25.725047] atyfb: using auxiliary register aperture
[   25.725125] atyfb: 3D RAGE II (Mach64 GT) [0x4754 rev 0x41]
[   25.725176] atyfb: Mach64 BIOS is located at c0000, mapped at c00c0000.
[   25.725228] atyfb: BIOS frequency table:
[   25.725281] atyfb: PCLK_min_freq 26465, PCLK_max_freq 24930, ref_freq 11829, ref_divider 12902
[   25.725337] atyfb: MCLK_pwd 12598, MCLK_max_freq 8241, XCLK_max_freq 22016, SCLK_freq 13619
[   25.725418] atyfb: 512K SDRAM (1:1), 14.31818 MHz XTAL, 249 MHz PLL, 82 Mhz MCLK, 220 MHz XCLK
[   25.725473] atyfb: Unsupported xclk source:  5.
[   25.725654] atyfb: vclk out of range
[   25.725703] atyfb: can't set default video mode
[   25.762829] PCI: Enabling device 0000:02:0c.0 (0080 -> 0083)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Morton | 4 Apr 2006 09:16

cirrusfb on sparc32

In file included from drivers/video/cirrusfb.c:69:
include/video/vga.h:24:21: asm/vga.h: No such file or directory

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |

Gmane