headers
Karel Zak | 1 Jun 2007 01:04
Picon
Favicon
Gravatar

Re: [RFC] obsoleting /etc/mtab

On Thu, May 31, 2007 at 09:40:49AM -0700, H. Peter Anvin wrote:
> Miklos Szeredi wrote:
> > 
> > (2) needs work in the filesystems implicated.  I already have patches
> > for ext2, ext3, tmpfs, devpts and hostfs, and it would be nice if the
> > maintainers for others could help out.
> > 
> 
> A lot of these could be fixed all at once by letting the filesystem tell
> the VFS to retain the string passed to the original mount.  That will

 Unfortunately, the original option string (from userspace) != real
 options (in kernel), see NFS. This bug should be fixed -- the kernel
 has to fully follow mount(2) or ends with EINVAL.

    Karel

--

-- 
 Karel Zak  <kzak@...>
Permalink | Reply | 10 comments |
headers
Steve French | 1 Jun 2007 01:08
Picon
Gravatar

[PATCH] support larger cifs network reads

With Samba 3.0.26pre it is now possible for a cifs client (one which
supports the newest Unix/Posix cifs extensions) to request up to
almost 8MB at a time on a cifs read request.

A patch for the cifs client to support larger reads follows.  In this
patch, using very large reads is not the default behavior, since it
would require larger buffer allocations for the large cifs request
buffers, but in the future when cifs can demultiplex reads to a page
list in the cifs_demultiplex_thread (without having to copy to a large
temporary buffer) this will be even more useful.

diff --git a/fs/cifs/README b/fs/cifs/README
index 4d01697..6ad722b 100644
--- a/fs/cifs/README
+++ b/fs/cifs/README
 <at>  <at>  -301,8 +301,19  <at>  <at>  A partial list of the supported mount op
 		during the local client kernel build will be used.
 		If server does not support Unicode, this parameter is
 		unused.
-  rsize		default read size (usually 16K)
-  wsize		default write size (usually 16K, 32K is often better over GigE)
+  rsize		default read size (usually 16K). The client currently
+		can not use rsize larger than CIFSMaxBufSize. CIFSMaxBufSize
+		defaults to 16K and may be changed (from 8K to the maximum
+		kmalloc size allowed by your kernel) at module install time
+		for cifs.ko. Setting CIFSMaxBufSize to a very large value
+		will cause cifs to use more memory and may reduce performance
+		in some cases.  To use rsize greater than 127K (the original
+		cifs protocol maximum) also requires that the server support
+		a new Unix Capability flag (for very large read) which some
(Continue reading)

Permalink | Reply | 2 comments |
headers
Trond Myklebust | 1 Jun 2007 01:30
Picon
Picon

Re: [RFC] obsoleting /etc/mtab

On Fri, 2007-06-01 at 01:04 +0200, Karel Zak wrote:
> On Thu, May 31, 2007 at 09:40:49AM -0700, H. Peter Anvin wrote:
> > Miklos Szeredi wrote:
> > > 
> > > (2) needs work in the filesystems implicated.  I already have patches
> > > for ext2, ext3, tmpfs, devpts and hostfs, and it would be nice if the
> > > maintainers for others could help out.
> > > 
> > 
> > A lot of these could be fixed all at once by letting the filesystem tell
> > the VFS to retain the string passed to the original mount.  That will
> 
>  Unfortunately, the original option string (from userspace) != real
>  options (in kernel), see NFS. This bug should be fixed -- the kernel
>  has to fully follow mount(2) or ends with EINVAL.

Way ahead of you... See patches 6 and 7 on

  http://client.linux-nfs.org/Linux-2.6.x/2.6.22-rc3/

Trond

-
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 | 8 comments |
headers
David Chinner | 1 Jun 2007 01:34
Picon
Favicon

Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.

On Thu, May 31, 2007 at 02:31:21PM -0400, Phillip Susi wrote:
> David Chinner wrote:
> >That sounds like a good idea - we can leave the existing
> >WRITE_BARRIER behaviour unchanged and introduce a new WRITE_ORDERED
> >behaviour that only guarantees ordering. The filesystem can then
> >choose which to use where appropriate....
> 
> So what if you want a synchronous write, but DON'T care about the order? 

submit_bio(WRITE_SYNC, bio);

Already there, already used by XFS, JFS and direct I/O.

Cheers,

Dave.
--

-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
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 | 11 comments |
headers
David Chinner | 1 Jun 2007 01:47
Picon
Favicon

Re: [RFC] obsoleting /etc/mtab

On Thu, May 31, 2007 at 09:40:49AM -0700, H. Peter Anvin wrote:
> Miklos Szeredi wrote:
> > 
> > (2) needs work in the filesystems implicated.  I already have patches
> > for ext2, ext3, tmpfs, devpts and hostfs, and it would be nice if the
> > maintainers for others could help out.
> > 
> 
> A lot of these could be fixed all at once by letting the filesystem tell
> the VFS to retain the string passed to the original mount.  That will
> solve *almost* all filesystems which take string options.

Except some filesystems mangle that string as it gets passed around
(i.e. XFS)....

Cheers,

Dave.
--

-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
Permalink | Reply | 0 comments |
headers
H. Peter Anvin | 1 Jun 2007 02:11
Favicon

Re: [RFC] obsoleting /etc/mtab

Trond Myklebust wrote:
>>>>
>>> A lot of these could be fixed all at once by letting the filesystem tell
>>> the VFS to retain the string passed to the original mount.  That will
>>  Unfortunately, the original option string (from userspace) != real
>>  options (in kernel), see NFS. This bug should be fixed -- the kernel
>>  has to fully follow mount(2) or ends with EINVAL.
> 
> Way ahead of you... See patches 6 and 7 on
> 
>   http://client.linux-nfs.org/Linux-2.6.x/2.6.22-rc3/
> 

NFS takes a binary option block anyway.  However, that's the exception,
not the rule.

	-hpa
Permalink | Reply | 6 comments |
headers
Nick Piggin | 1 Jun 2007 03:18
Picon

Re: [patch 12/41] fs: introduce write_begin, write_end, and perform_write aops

On Thu, May 31, 2007 at 12:05:39AM -0700, Andrew Morton wrote:
> On Thu, 31 May 2007 07:15:39 +0200 Nick Piggin <npiggin <at> suse.de> wrote:
> 
> > If you can send that rollup, it would be good. I could try getting
> > everything to compile and do some more testing on it too.
> 
> 
> Single patch against 2.6.22-rc3: http://userweb.kernel.org/~akpm/np.gz
> 
> broken-out: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-05-30-09-30.tar.gz

Thanks, I'll get onto it.
-
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
Tejun Heo | 1 Jun 2007 05:16
Picon

Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.

Jens Axboe wrote:
> On Thu, May 31 2007, David Chinner wrote:
>> On Thu, May 31, 2007 at 08:26:45AM +0200, Jens Axboe wrote:
>>> On Thu, May 31 2007, David Chinner wrote:
>>>> IOWs, there are two parts to the problem:
>>>>
>>>> 	1 - guaranteeing I/O ordering
>>>> 	2 - guaranteeing blocks are on persistent storage.
>>>>
>>>> Right now, a single barrier I/O is used to provide both of these
>>>> guarantees. In most cases, all we really need to provide is 1); the
>>>> need for 2) is a much rarer condition but still needs to be
>>>> provided.
>>>>
>>>>> if I am understanding it correctly, the big win for barriers is that you 
>>>>> do NOT have to stop and wait until the data is on persistant media before 
>>>>> you can continue.
>>>> Yes, if we define a barrier to only guarantee 1), then yes this
>>>> would be a big win (esp. for XFS). But that requires all filesystems
>>>> to handle sync writes differently, and sync_blockdev() needs to
>>>> call blkdev_issue_flush() as well....
>>>>
>>>> So, what do we do here? Do we define a barrier I/O to only provide
>>>> ordering, or do we define it to also provide persistent storage
>>>> writeback? Whatever we decide, it needs to be documented....
>>> The block layer already has a notion of the two types of barriers, with
>>> a very small amount of tweaking we could expose that. There's absolutely
>>> zero reason we can't easily support both types of barriers.
>> That sounds like a good idea - we can leave the existing
>> WRITE_BARRIER behaviour unchanged and introduce a new WRITE_ORDERED
(Continue reading)

Permalink | Reply | 17 comments |
headers
Tejun Heo | 1 Jun 2007 05:25
Picon

Re: Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.

Stefan Bader wrote:
> 2007/5/30, Phillip Susi <psusi <at> cfl.rr.com>:
>> Stefan Bader wrote:
>> >
>> > Since drive a supports barrier request we don't get -EOPNOTSUPP but
>> > the request with block y might get written before block x since the
>> > disk are independent. I guess the chances of this are quite low since
>> > at some point a barrier request will also hit drive b but for the time
>> > being it might be better to indicate -EOPNOTSUPP right from
>> > device-mapper.
>>
>> The device mapper needs to ensure that ALL underlying devices get a
>> barrier request when one comes down from above, even if it has to
>> construct zero length barriers to send to most of them.
>>
> 
> And somehow also make sure all of the barriers have been processed
> before returning the barrier that came in. Plus it would have to queue
> all mapping requests until the barrier is done (if strictly acting
> according to barrier.txt).
> 
> But I am wondering a bit whether the requirements to barriers are
> really that tight as described in Tejun's document (barrier request is
> only started if everything before is safe, the barrier itself isn't
> returned until it is safe, too, and all requests after the barrier
> aren't started before the barrier is done). Is it really necessary to
> defer any further requests until the barrier has been written to save
> storage? Or would it be sufficient to guarantee that, if a barrier
> request returns, everything up to (including the barrier) is on safe
> storage?
(Continue reading)

Permalink | Reply | 49 comments |
headers
Andreas Dilger | 1 Jun 2007 06:30

Re: [RFC] obsoleting /etc/mtab

On May 31, 2007  17:11 -0700, H. Peter Anvin wrote:
> NFS takes a binary option block anyway.  However, that's the exception,
> not the rule.

There was recently a patch submitted to linux-fsdevel to change NFS to
use text option parsing.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
Permalink | Reply | 0 comments |

Gmane