On Wed, May 09, 2007 at 09:31:02PM +0530, Amit K. Arora wrote:
> I have the updated patches ready which take care of Andrew's comments.
> Will run some tests and post them soon.
>
> But, before submitting these patches, I think it will be better to finalize
> on certain things which might be worth
On Wed, 9 May 2007 14:51:41 -0500, Matt Mackall wrote:
> On Wed, May 09, 2007 at 11:59:23AM -0700, Valerie Henson wrote:
> >
> > Hrm. Can you help me understand how you would check i_size then?
>
> That's pretty straightforward, I think. When we check an inode, we
> have to check whether it has
David Howells wrote:
+/*
+ * prepare a page for being written to
+ */
+static int afs_prepare_page(struct afs_vnode *vnode, struct page *page,
+ struct key *key, unsigned offset, unsigned to)
+{
+ unsigned eof, tail, start, stop, len;
+ loff_t i_size, pos;
+
From: David Howells <[EMAIL PROTECTED]>
Date: Wed, 09 May 2007 14:51:47 +0100
> Reduce debugging noise generated by AF_RXRPC.
>
> Signed-off-by: David Howells <[EMAIL PROTECTED]>
Applied, thanks David.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a me
On Wed, May 09, 2007 at 12:01:13PM -0700, Valerie Henson wrote:
> On Sun, Apr 29, 2007 at 08:40:42PM -0500, Matt Mackall wrote:
> > On Sun, Apr 29, 2007 at 07:23:49PM -0400, Theodore Tso wrote:
> > > There are a number of filesystem corruptions this algorithm won't
> > > catch. The most obvious is
On Wed, May 09, 2007 at 11:59:23AM -0700, Valerie Henson wrote:
> On Wed, May 09, 2007 at 12:06:52PM -0500, Matt Mackall wrote:
> > On Wed, May 09, 2007 at 12:56:39AM -0700, Valerie Henson wrote:
> > > On Sun, Apr 29, 2007 at 08:40:42PM -0500, Matt Mackall wrote:
> > > >
> > > > This does mean tha
Valerie Henson writes:
[...]
>
> You're right about needing to read the equivalent data-structure - for
> other reasons, each continuation inode will need an easily accessible
> list of byte ranges covered by that inode. (Sounds like, hey,
> extents!) The important part is that you don't ha
On Sun, Apr 29, 2007 at 08:40:42PM -0500, Matt Mackall wrote:
> On Sun, Apr 29, 2007 at 07:23:49PM -0400, Theodore Tso wrote:
> > There are a number of filesystem corruptions this algorithm won't
> > catch. The most obvious is one where the directory tree isn't really
> > a tree, but an cyclic gra
On Wed, May 09, 2007 at 12:06:52PM -0500, Matt Mackall wrote:
> On Wed, May 09, 2007 at 12:56:39AM -0700, Valerie Henson wrote:
> > On Sun, Apr 29, 2007 at 08:40:42PM -0500, Matt Mackall wrote:
> > >
> > > This does mean that our time to make progress on a check is bounded at
> > > the top by the
On Wed, May 09, 2007 at 03:16:41PM +0400, Nikita Danilov wrote:
>
> I guess I miss something. If chunkfs maintains "at most one continuation
> per chunk" invariant, then continuation inode might end up with multiple
> byte ranges, and to check that they do not overlap one has to read
> indirect bl
On Wed, 2007-05-09 at 21:31 +0530, Amit K. Arora wrote:
> I have the updated patches ready which take care of Andrew's comments.
> Will run some tests and post them soon.
>
> But, before submitting these patches, I think it will be better to finalize
> on certain things which might be worth some d
On Wed, May 09, 2007 at 12:56:39AM -0700, Valerie Henson wrote:
> On Sun, Apr 29, 2007 at 08:40:42PM -0500, Matt Mackall wrote:
> >
> > This does mean that our time to make progress on a check is bounded at
> > the top by the size of our largest file. If we have a degenerate
> > filesystem filled
On May 09, 2007 21:31 +0530, Amit K. Arora wrote:
> 2) For FA_UNALLOCATE mode, should the file system allow unallocation
>of normal (non-preallocated) blocks (blocks allocated via
>regular write/truncate operations) also (i.e. work as punch()) ?
>- Though FA_UNALLOCATE mode is yet to b
On Wed, 09 May 2007 12:07:39 +0100 David Howells <[EMAIL PROTECTED]> wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > set_page_dirty() will set I_DIRTY_PAGES only. ie: the inode has dirty
> > pagecache data.
> >
> > To tell the VFS that the inode itself is dirty one needs to run
> > mark
I have the updated patches ready which take care of Andrew's comments.
Will run some tests and post them soon.
But, before submitting these patches, I think it will be better to finalize
on certain things which might be worth some discussion here:
1) Should the file size change when preallocation
Reduce debugging noise generated by AF_RXRPC.
Signed-off-by: David Howells <[EMAIL PROTECTED]>
---
net/rxrpc/ar-peer.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/rxrpc/ar-peer.c b/net/rxrpc/ar-peer.c
index ce08b78..90fa107 100644
--- a/net/rxrpc/ar-peer.c
+++
Further fixes for AFS write support:
(1) The afs_send_pages() outer loop must do an extra iteration if it ends
with 'first == last' because 'last' is inclusive in the page set
otherwise it fails to send the last page and complete the RxRPC op under
some circumstances.
(2) Similar
On May 8 2007 20:17, Evgeniy Polyakov wrote:
>> > >> +static int __logfs_readdir(struct file *file, void *buf, filldir_t
>> > >> filldir)
>> > >> +{
>> > >> + err = read_dir(dir, &dd, pos);
>> > >> + if (err == -EOF)
>> > >> + break;
>> > >
>> > >
AFS write support fixes:
(1) Support large files using the 64-bit file access operations if available
on the server.
(2) Use kmap_atomic() rather than kmap() in afs_prepare_page().
(3) Don't do stuff in afs_writepage() that's done by the caller.
Signed-off-by: David Howells <[EMAIL PROT
On Wed, May 09, 2007 at 09:37:22PM +1000, Paul Mackerras wrote:
> Suparna Bhattacharya writes:
>
> > > Of course the interface used by an application program would have the
> > > fd first. Glibc can do the translation.
> >
> > I think that was understood.
>
> OK, then what does it matter what t
On 5/9/07, Paul Mackerras <[EMAIL PROTECTED]> wrote:
Suparna Bhattacharya writes:
> > Of course the interface used by an application program would have the
> > fd first. Glibc can do the translation.
>
> I think that was understood.
OK, then what does it matter what the glibc/kernel interface
Suparna Bhattacharya writes:
> > Of course the interface used by an application program would have the
> > fd first. Glibc can do the translation.
>
> I think that was understood.
OK, then what does it matter what the glibc/kernel interface is, as
long as it works?
It's only a minor point; the
Valerie Henson writes:
[...]
>
> Hm, I'm not sure that everyone understands, a particular subtlety of
> how the fsck algorithm works in chunkfs. A lot of people seem to
> think that you need to check *all* cross-chunk links, every time an
> individual chunk is checked. That's not the case
On Mon 07-05-07 09:28:30, Greg KH wrote:
> On Fri, May 04, 2007 at 04:14:28PM +0200, Jan Kara wrote:
> > On Thu 03-05-07 17:16:02, Greg KH wrote:
> > > On Thu, May 03, 2007 at 11:54:52AM +0200, Jan Kara wrote:
> > > > On Tue 01-05-07 20:26:27, Greg KH wrote:
> > > > > On Mon, Apr 30, 2007 at 07:55:
On Wed, May 09, 2007 at 08:50:44PM +1000, Paul Mackerras wrote:
> Suparna Bhattacharya writes:
>
> > > This looks like it will have the same problem on s390 as
> > > sys_sync_file_range. Maybe the prototype should be:
> > >
> > > asmlinkage long sys_fallocate(loff_t offset, loff_t len, int fd, i
Andrew Morton <[EMAIL PROTECTED]> wrote:
> set_page_dirty() will set I_DIRTY_PAGES only. ie: the inode has dirty
> pagecache data.
>
> To tell the VFS that the inode itself is dirty one needs to run
> mark_inode_dirty().
But what's the difference in this case? I don't need to write the inode b
Suparna Bhattacharya writes:
> > This looks like it will have the same problem on s390 as
> > sys_sync_file_range. Maybe the prototype should be:
> >
> > asmlinkage long sys_fallocate(loff_t offset, loff_t len, int fd, int mode)
>
> Yes, but the trouble is that there was a contrary viewpoint pr
On Wed, 09 May 2007 11:25:47 +0100 David Howells <[EMAIL PROTECTED]> wrote:
> > > + set_page_dirty(page);
> > > +
> > > + if (PageDirty(page))
> > > + _debug("dirtied");
> > > +
> > > + return 0;
> > > +}
> >
> > One would normally run mark_inode_dirty() after any i_size_write()?
>
> Not
On Tue, 8 May 2007 17:01:01 -0700, Greg KH wrote:
> On Wed, May 09, 2007 at 01:10:09AM +0200, J??rn Engel wrote:
> >
> > The remaining question is how to deal with kernel-only code that uses
> > be64. Convert that to __be64 as well? Or introduce be64 in
> > include/linix/types.h instead?
>
> I
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > + BUG_ON(i_size > 0x); // TODO: use 64-bit store
>
> You're sure this isn't user-triggerable?
Hmmm... I'm not. I'll whip up a patch for this.
> kmap_atomic() could be used here and is better.
Yeah. It used to have something that slept i
On Tue, 8 May 2007 22:56:09 -0700, Valerie Henson wrote:
>
> I like it too, especially the rmap stuff, but I don't think it solves
> some of the problems chunkfs solves. The really nice thing about
> chunkfs is that it tries hard to isolate each chunk from all the other
> chunks. You can think o
On Fri, May 04, 2007 at 02:41:50PM +1000, Paul Mackerras wrote:
> Andrew Morton writes:
>
> > On Thu, 26 Apr 2007 23:33:32 +0530 "Amit K. Arora" <[EMAIL PROTECTED]>
> > wrote:
> >
> > > This patch implements the fallocate() system call and adds support for
> > > i386, x86_64 and powerpc.
> > >
On Sun, Apr 29, 2007 at 08:40:42PM -0500, Matt Mackall wrote:
>
> This does mean that our time to make progress on a check is bounded at
> the top by the size of our largest file. If we have a degenerate
> filesystem filled with a single file, this will in fact take as long
> as a conventional fsc
33 matches
Mail list logo
