On Mon, Jun 25, 2007 at 05:25:00PM -0500, Steve French wrote:
> Jeff,
> Not seeing any objections to your revised approach (to not allowing
> signals for cifsd kernel thread), I just merged something similar to
> your patch to the cifs-2.6.git tree (also fixed some nearby lines that
> went past 80
On Mon, Jun 25, 2007 at 05:08:02PM -0700, Jared Hulbert wrote:
> -memory mappable swap file (I'm not sure if this one is appropriate
> for the proposed meeting)
Please explain what this is supposed to mean.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of
On Tuesday June 26, [EMAIL PROTECTED] wrote:
>
> Thanks for the brief howto there. I'll install the mdadm suite and
> experiment. It seems like a userspace driver?
mdadm is a userspace tool for managing the 'md' driver which is in the
linux kernel.
> > I don't know what you mean by '2'.
>
> 2 m
Neil Brown wrote:
???
(reads original description in more detail).
So... the filesystem images are identical in both copies, and the
"interesting" bit is that the image is just a file on some filesystem.
So could I implement your idea by:
dd if=/dev/zero of=/1/bigfile count=lotsandlots
dd
David Chinner wrote:
On Sun, Jun 24, 2007 at 03:45:28AM +0200, Nick Piggin wrote:
I'm announcing "fsblock" now because it is quite intrusive and so I'd
like to get some thoughts about significantly changing this core part
of the kernel.
Can you rename it to something other than shorthand for
On Tuesday June 26, [EMAIL PROTECTED] wrote:
> Neil Brown wrote:
> >
> > Sounds a lot like "RAIF" - ask google for details.
>
> I did not know about RAIF. RAIF "merges" separate filesystems? That is a
> good idea in itself.
>
> My idea is for driver that provides a filesystem from image files it
On Jun 26, 2007 12:35 +1000, Nick Piggin wrote:
> Leaving my opinion of higher order pagecache aside, this _may_ be an
> example of something that doesn't need a lot of attention, because it
> should be fairly uncontroversial from a filesystem's POV? (eg. it is
> more a relevant item to memory man
Neil Brown wrote:
On Tuesday June 26, [EMAIL PROTECTED] wrote:
Posting it here seems the best thing to do.
To the inventor goes naming privilege and I'm calling this one softer raid.
It is a form of storage raid implemented in software, as contrasted to
software and hardware raid which are depe
Neil Brown wrote:
On Tuesday June 26, [EMAIL PROTECTED] wrote:
Chris Mason wrote:
The block device pagecache isn't special, and certainly isn't that much
code. I would suggest keeping it buffer head specific and making a
second variant that does only fsblocks. This is mostly to keep the
sem
On Sun, Jun 24, 2007 at 03:45:28AM +0200, Nick Piggin wrote:
>
> I'm announcing "fsblock" now because it is quite intrusive and so I'd
> like to get some thoughts about significantly changing this core part
> of the kernel.
Can you rename it to something other than shorthand for
"filesystem block
On Tuesday June 26, [EMAIL PROTECTED] wrote:
> Chris Mason wrote:
> >
> > The block device pagecache isn't special, and certainly isn't that much
> > code. I would suggest keeping it buffer head specific and making a
> > second variant that does only fsblocks. This is mostly to keep the
> > sema
Chris Mason wrote:
On Sun, Jun 24, 2007 at 03:46:13AM +0200, Nick Piggin wrote:
Rewrite the buffer layer.
Overall, I like the basic concepts, but it is hard to track the locking
rules. Could you please write them up?
Yeah I will do that.
Thanks for taking a look. One thing I am thinking
Christoph Hellwig wrote:
On Sun, Jun 24, 2007 at 06:23:45AM +0200, Nick Piggin wrote:
I'd just like to take the chance also to ask about a VM/FS meetup some
time around kernel summit (maybe take a big of time during UKUUG or so).
I won't be around until a day or two before KS, so I'd prefer
Chris Mason wrote:
On Mon, Jun 25, 2007 at 05:41:58PM +1000, Nick Piggin wrote:
Neil Brown wrote:
Why do you think you need PG_blocks?
Block device pagecache (buffer cache) has to be able to accept
attachment of either buffers or blocks for filesystem metadata,
and call into either buffer.
On Tuesday June 26, [EMAIL PROTECTED] wrote:
> Posting it here seems the best thing to do.
>
> To the inventor goes naming privilege and I'm calling this one softer raid.
> It is a form of storage raid implemented in software, as contrasted to
> software and hardware raid which are dependent on us
Posting it here seems the best thing to do.
To the inventor goes naming privilege and I'm calling this one softer raid.
It is a form of storage raid implemented in software, as contrasted to
software and hardware raid which are dependent on using required hardware.
To create a loop filesystem is
>If your only purpose is to try generate a defensive patent, then just
>dumping the idea in the public domain serves the same purpose, probably
>better.
>
>I have a few patents, some of which are defensive. That has not prevented
>the USPTO issuing quite a few patents that are in clear violation of
A few things I'd like to talk about are:
- the address space operations APIs, and their page based nature. I think
it would be nice to generally move toward offset,length based ones as
much as possible because it should give more efficiency and flexibility
in the filesystem.
- write_begin
> Dear devs,
>
> In a moment of serendipity I thought of a concept which may be
> advantageous
> if incorporated into the kernel. I was going to offer it to the OIN but
> they responded they only consider existing patents and I don't have the
> money to afford one.
>
> I am seeking advice on how to
On Tue, 26 Jun 2007 09:45:22 +1200
Graeme Sheppard <[EMAIL PROTECTED]> wrote:
> I am seeking advice on how to proceed. It could be used as a defensive
> patent in which case I can email an expert who can file it. If that is the
> concept is sound. I am not expecting any royalties from this myself.
On Tue, 26 Jun 2007, Graeme Sheppard wrote:
alan wrote:
On Tue, 26 Jun 2007, Graeme Sheppard wrote:
Dear devs,
In a moment of serendipity I thought of a concept which may be
advantageous
if incorporated into the kernel. I was going to offer it to the OIN but
they responded they only consid
alan wrote:
On Tue, 26 Jun 2007, Graeme Sheppard wrote:
Dear devs,
In a moment of serendipity I thought of a concept which may be advantageous
if incorporated into the kernel. I was going to offer it to the OIN but
they responded they only consider existing patents and I don't have the
money t
Jeff,
Not seeing any objections to your revised approach (to not allowing
signals for cifsd kernel thread), I just merged something similar to
your patch to the cifs-2.6.git tree (also fixed some nearby lines that
went past 80 columns).
Thanks
Signed-off-by: Jeff Layton <[EMAIL PROTECTED]>
di
On Tue, 26 Jun 2007, Graeme Sheppard wrote:
Dear devs,
In a moment of serendipity I thought of a concept which may be advantageous
if incorporated into the kernel. I was going to offer it to the OIN but
they responded they only consider existing patents and I don't have the
money to afford one.
Please check if the following modified patch meets the requirements.
It augments /proc/mount with additional information to
(1) disambiguate bind mounts with subroot information.
(2) display shared-subtree information using which one can
determine the propagation tr
Dear devs,
In a moment of serendipity I thought of a concept which may be advantageous
if incorporated into the kernel. I was going to offer it to the OIN but
they responded they only consider existing patents and I don't have the
money to afford one.
I am seeking advice on how to proceed. It co
On Jun 25, 2007 19:20 +0530, Amit K. Arora wrote:
> @@ -2499,7 +2500,8 @@ long ext4_fallocate(struct inode *inode,
>* currently supporting (pre)allocate mode for extent-based
>* files _only_
>*/
> - if (mode != FA_ALLOCATE || !(EXT4_I(inode)->i_flags & EXT4_EXTENTS_FL))
On Jun 25, 2007 19:15 +0530, Amit K. Arora wrote:
> +#define FA_FL_DEALLOC0x01 /* default is allocate */
> +#define FA_FL_KEEP_SIZE 0x02 /* default is extend/shrink size */
> +#define FA_FL_DEL_DATA 0x04 /* default is keep written data on DEALLOC
> */
In XFS one of the (many)
On Jun 25, 2007 20:33 +0530, Amit K. Arora wrote:
> I have not implemented FA_FL_FREE_ENOSPC and FA_ZERO_SPACE flags yet, as
> *suggested* by Andreas in http://lkml.org/lkml/2007/6/14/323 post.
> If it is decided that these flags are also needed, I will update this
> patch. Thanks!
Can you clari
On Mon, 25 Jun 2007, Pavel Machek wrote:
Hi!
We've been over the "AA is different" discussion in threads about a
billion times, and at the last kernel summit. I think Lars and others
have done a pretty good job of describing the problems they are trying
to solve, can we please move on to disc
On Mon, Jun 25, 2007 at 12:34:36PM +0300, Pekka Enberg wrote:
>
> Hi Borislav,
>
> On 6/24/2007, "Borislav Petkov" <[EMAIL PROTECTED]> wrote:
> > @@ -3,7 +3,7 @@
> >
> > Original author: Richard Gooch <[EMAIL PROTECTED]>
> >
> > - Last updated on October 28, 2005
> > +
> > I'd suggest something along these lines in final mntput:
> >
> > lock_and_coalesce_cpu_mnt_writer_counts();
> > mnt_unlock_cpus();
> > BUG_ON(atomic_read(&mnt->__mnt_writers));
> >
> > since there's basically no other we'll notice if there _is_ an
> > imbalance.
>
> T
Hi!
> We've been over the "AA is different" discussion in threads about a
> billion times, and at the last kernel summit. I think Lars and others
> have done a pretty good job of describing the problems they are trying
> to solve, can we please move on to discussing technical issues around
> that
On Sat, 2007-06-23 at 08:46 +0100, Christoph Hellwig wrote:
> On Fri, Jun 22, 2007 at 01:03:21PM -0700, Dave Hansen wrote:
> > Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
>
> We really want a guaranteed non-NULL file here, but I don't want to put
> this on your plate also. Please add a comment
On Sat, 2007-06-23 at 08:45 +0100, Christoph Hellwig wrote:
> On Fri, Jun 22, 2007 at 01:03:14PM -0700, Dave Hansen wrote:
> >
> > It is OK to let access() go without using a mnt_want/drop_write()
> > pair because it doesn't actually do writes to the filesystem,
> > and it is inherently racy anywa
On Mon, 2007-06-25 at 10:25 -0700, Andrew Morton wrote:
> On Mon, 25 Jun 2007 08:37:29 -0700 Dave Hansen <[EMAIL PROTECTED]> wrote:
> > On Sat, 2007-06-23 at 09:52 -0700, Andrew Morton wrote:
> > > The net/socket.c change is a mystery. My version of sock_attach_fd()
> > > doesn't look like yours.
> > I'd just like to take the chance also to ask about a VM/FS meetup some
> > time around kernel summit (maybe take a big of time during UKUUG or so).
Yeah, I'd be interested.
> More issues:
- chris mason's patches to normalize buffered and direct locking
- z
-
To unsubscribe from this list: s
On Mon, 25 Jun 2007 08:37:29 -0700 Dave Hansen <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-06-23 at 09:52 -0700, Andrew Morton wrote:
> > > On Fri, 22 Jun 2007 13:03:08 -0700 Dave Hansen <[EMAIL PROTECTED]> wrote:
> > > Christoph H. says this stands on its own and can go in before the
> > > rest of
Hi,
I came across the following question: What is the proper locking for
using i_flags? I've noticed i_flags are read freely without any lock.
The modifications I've seen e.g. in ext3 were done under i_mutex. Is this
right?
BTW it means that when checking i_flags we can see intermediate stat
On Mon, 25 June 2007 19:40:02 +0900, Dongjun Shin wrote:
>
> I'm working on the Linux optimization for the flash SSD (Solid State Disk),
> which is becoming more practical nowadays (it's not a pipe dream any more :)
>
> During my work, I've found that Linux does not perform so well on SSD.
> The
On Sat, 2007-06-23 at 09:52 -0700, Andrew Morton wrote:
> > On Fri, 22 Jun 2007 13:03:09 -0700 Dave Hansen <[EMAIL PROTECTED]> wrote:
> > This patch adds two function mnt_want_write() and
> > mnt_drop_write()
>
> ITYM "global, exported-to-modules yet 100% undocumented" functions.
Point taken. :)
On Sat, 2007-06-23 at 09:52 -0700, Andrew Morton wrote:
> > On Fri, 22 Jun 2007 13:03:36 -0700 Dave Hansen <[EMAIL PROTECTED]>
> wrote:
> > +DEFINE_PER_CPU(struct mnt_writer, mnt_writers);
>
> this can have static scope.
Fixed. That'll be in my update.
-- Dave
-
To unsubscribe from this list:
On Sat, 2007-06-23 at 09:52 -0700, Andrew Morton wrote:
> > On Fri, 22 Jun 2007 13:03:03 -0700 Dave Hansen <[EMAIL PROTECTED]> wrote:
> > Why do we need r/o bind mounts?
> >
> > This feature allows a read-only view into a read-write filesystem.
> > In the process of doing that, it also provides in
On Sat, 2007-06-23 at 09:52 -0700, Andrew Morton wrote:
> > On Fri, 22 Jun 2007 13:03:08 -0700 Dave Hansen <[EMAIL PROTECTED]> wrote:
> > Christoph H. says this stands on its own and can go in before the
> > rest of the r/o bind mount set.
> >
> > ---
> >
> > Some filesystems forego the vfs and
On Sat, 2007-06-23 at 13:28 +0200, Miklos Szeredi wrote:
>
> I'd suggest something along these lines in final mntput:
>
> lock_and_coalesce_cpu_mnt_writer_counts();
> mnt_unlock_cpus();
> BUG_ON(atomic_read(&mnt->__mnt_writers));
>
> since there's basically no other we'll
On Sat, 2007-06-23 at 08:51 +0100, Christoph Hellwig wrote:
> > diff -puN
> > fs/namei.c~18-24-sys-mknodat-elevate-write-count-for-vfs-mknod-create
> > fs/namei.c
> > ---
> > lxc/fs/namei.c~18-24-sys-mknodat-elevate-write-count-for-vfs-mknod-create
> > 2007-06-21 23:23:25.0 -0700
> > ++
On Sat, 2007-06-23 at 08:40 +0100, Christoph Hellwig wrote:
>
> > Some filesystems forego the use of normal vfs calls to create
> > struct files. Make sure that these users elevate the mnt writer
> > count because they will get __fput(), and we need to make
> > sure they're balanced.
>
> With th
On Sat, 2007-06-23 at 08:47 +0100, Christoph Hellwig wrote:
> On Fri, Jun 22, 2007 at 01:03:22PM -0700, Dave Hansen wrote:
> > This area of code is currently #ifdef'd out, so add a comment
> > for the time when it is actually used.
>
> Ok. Does this clash with the user mount patches? Even if it
I have not implemented FA_FL_FREE_ENOSPC and FA_ZERO_SPACE flags yet, as
*suggested* by Andreas in http://lkml.org/lkml/2007/6/14/323 post.
If it is decided that these flags are also needed, I will update this
patch. Thanks!
On Mon, Jun 25, 2007 at 07:15:00PM +0530, Amit K. Arora wrote:
> Impleme
On Sat, 2007-06-23 at 08:38 +0100, Christoph Hellwig wrote:
> Note that we've grown more instances of the crap you're fixing here,
> e.g. fs/anon_inode.c
Ugh. I'll go clean that one up.
-- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message t
Support new values of mode in ext4.
This patch supports new mode values/flags in ext4. With this patch ext4
will be able to support FA_ALLOCATE and FA_RESV_SPACE modes. Supporting
FA_DEALLOCATE and FA_UNRESV_SPACE fallocate modes in ext4 is a work for
future.
Signed-off-by: Amit Arora <[EMAIL PRO
This patch adds write support to the uninitialized extents that get
created when a preallocation is done using fallocate(). It takes care of
splitting the extents into multiple (upto three) extents and merging the
new split extents with neighbouring ones, if possible.
Changelog:
-
Changes
This patch implements ->fallocate() inode operation in ext4. With this
patch users of ext4 file systems will be able to use fallocate() system
call for persistent preallocation.
Current implementation only supports preallocation for regular files
(directories not supported as of date) with extent
Implement new flags and values for mode argument.
This patch implements the new flags and values for the "mode" argument
of the fallocate system call. It is based on the discussion between
Andreas Dilger and David Chinner on the man page proposed (by the later)
on fallocate.
Signed-off-by: Amit A
fallocate() on ia64
ia64 fallocate syscall support.
Signed-off-by: Dave Chinner <[EMAIL PROTECTED]>
Index: linux-2.6.22-rc4/arch/ia64/kernel/entry.S
===
--- linux-2.6.22-rc4.orig/arch/ia64/kernel/entry.S 2007-06-11
17:22:15.00
This is the patch suggested by Martin Schwidefsky to support
sys_fallocate() on s390(x) platform.
He also suggested a wrapper in glibc to handle this system call on
s390. Posting it here so that we get feedback for this too.
.globl __fallocate
ENTRY(__fallocate)
stm %r6,%r7,28(%r15)
This patch implements sys_fallocate() and adds support on i386, x86_64
and powerpc platforms.
Changelog:
-
Changes from Take3 to Take4:
1) Do not update c/mtime. Let each filesystem update ctime (update of
mtime will not be required for allocation since we touch only
metadata/inod
N O T E:
---
1) Only Patches 4/7 and 7/7 are NEW. Rest of them are _already_ part
of ext4 patch queue git tree hosted by Ted.
2) The above new patches (4/7 and 7/7) are based on the dicussion
between Andreas Dilger and David Chinner on the mode argument,
when later posted a man page o
On Sun, Jun 24, 2007 at 03:46:13AM +0200, Nick Piggin wrote:
> Rewrite the buffer layer.
Overall, I like the basic concepts, but it is hard to track the locking
rules. Could you please write them up?
I like the way you split out the assoc_buffers from the main fsblock
code, but the list setup is
On Mon, Jun 25, 2007 at 05:41:58PM +1000, Nick Piggin wrote:
> Neil Brown wrote:
> >On Sunday June 24, [EMAIL PROTECTED] wrote:
> >
> >>
> >>+#define PG_blocks 20 /* Page has block mappings */
> >>+
> >
> >
> >I've only had a very quick look, but this line looks *very* wrong.
> >You s
On Mon, Jun 25, 2007 at 04:58:48PM +1000, Nick Piggin wrote:
>
> >Using buffer heads instead allows the FS to send file data down inside
> >the transaction code, without taking the page lock. So, locking wrt
> >data=ordered is definitely going to be tricky.
> >
> >The best long term option may be
Hello,
I'm working on the Linux optimization for the flash SSD (Solid State Disk),
which is becoming more practical nowadays (it's not a pipe dream any more :)
During my work, I've found that Linux does not perform so well on SSD.
The most important issue, I suspect, is the behavior of the Linux
Hi Borislav,
On 6/24/2007, "Borislav Petkov" <[EMAIL PROTECTED]> wrote:
> @@ -3,7 +3,7 @@
>
> Original author: Richard Gooch <[EMAIL PROTECTED]>
>
> - Last updated on October 28, 2005
> + Last updated on Juni 24, 2007.
There's a typo here so do s/Juni/June/g p
On Sun, Jun 24, 2007 at 01:18:42PM -0700, Arjan van de Ven wrote:
>
> > Hmm, could define a macro DECLARE_ATOMIC_BITMAP(maxbit) that expands to the
> > smallest
> > possible type for each architecture. And a couple of ugly casts for set_bit
> > et.al.
> > but those could be also hidden in macros
Neil Brown wrote:
On Sunday June 24, [EMAIL PROTECTED] wrote:
+#define PG_blocks 20 /* Page has block mappings */
+
I've only had a very quick look, but this line looks *very* wrong.
You should be using PG_private.
There should never be any confusion about whether ->priva
Andi Kleen wrote:
Nick Piggin <[EMAIL PROTECTED]> writes:
[haven't read everything, just commenting on something that caught my eye]
+struct fsblock {
+ atomic_tcount;
+ union {
+ struct {
+ unsigned long flags; /* XXX: flags could be
Andi Kleen wrote:
Nick Piggin <[EMAIL PROTECTED]> writes:
- Structure packing. A page gets a number of buffer heads that are
allocated in a linked list. fsblocks are allocated contiguously, so
cacheline footprint is smaller in the above situation.
It would be interesting to test if that ma
Chris Mason wrote:
On Sun, Jun 24, 2007 at 05:47:55AM +0200, Nick Piggin wrote:
My gut feeling is that there are several problem areas you haven't hit
yet, with the new code.
I would agree with your gut :)
Without having read the code yet (light reading for monday morning ;),
ext3 and re
68 matches
Mail list logo
