On Friday, September 23, 2011 11:16 AM, Joe Perches wrote:
> On Fri, 2011-09-23 at 11:07 -0700, H Hartley Sweeten wrote:
>> Quiet the following sparse warnings:
> []
>> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
> []
>> @@ -2705,7 +2705,7 @@ long btrfs_ioctl_space_info(struct btrfs_root *root
On Thu, 22 Sep 2011 18:45:56 PDT, H Hartley Sweeten said:
> Quiet the sparse noise:
>
> warning: symbol '__lookup_extent_mapping' was not declared. Should it be
> static?
Patch itself is correct, changelog is bad. You're not quieting sparse noise,
you're making a declaration static because it d
Quiet the following sparse noise:
warning: symbol 'btrfs_first_delayed_node' was not declared. Should it be
static?
warning: symbol 'btrfs_next_delayed_node' was not declared. Should it be static?
warning: symbol 'btrfs_first_prepared_delayed_node' was not declared. Should it
be static?
warning:
Quiet the sparse warning:
warning: symbol 'btrfs_compress_op' was not declared. Should it be static?
Signed-off-by: H Hartley Sweeten
Cc: Chris Mason
---
diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
index 8ec5d86..3e8c133 100644
--- a/fs/btrfs/compression.c
+++ b/fs/btrfs/com
Quiet the following sparse warnings:
warning: symbol '__create_free_space_inode' was not declared. Should it be
static?
warning: symbol '__load_free_space_cache' was not declared. Should it be static?
warning: symbol '__btrfs_write_out_cache' was not declared. Should it be static?
warning: symbol
On Fri, 2011-09-23 at 11:07 -0700, H Hartley Sweeten wrote:
> Quiet the following sparse warnings:
[]
> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
[]
> @@ -2705,7 +2705,7 @@ long btrfs_ioctl_space_info(struct btrfs_root *root,
> void __user *arg)
> up_read(&info->groups_sem);
>
Quiet the following sparse warnings:
warning: cast removes address space of expression
warning: incorrect type in assignment (different address spaces)
expected struct btrfs_ioctl_space_info [noderef] *user_dest
got struct btrfs_ioctl_space_info *
warning: symbol 'btrfs_ioctl_space_info' was
On Fri, Sep 23, 2011 at 11:34:40AM -0400, Josef Bacik wrote:
> Yeah this is a different problem that's fixed upstream, so reboot into
> your other newer kernel with -o clear_cache. Thanks,
Ok I'm back in business now, thanks...
Now I'll try to understand why my pc sometimes hangs doing write IOs
On 09/23/2011 11:31 AM, Mathieu Chouquet-Stringer wrote:
> On Fri, Sep 23, 2011 at 10:49:22AM -0400, Josef Bacik wrote:
>> Ok I have no idea how this could happen. Can you mount -o clear_cache
>> and see if it's just the cache that's bad? Thanks,
>
> Did that and got this (it's a never ending st
On Fri, Sep 23, 2011 at 10:49:22AM -0400, Josef Bacik wrote:
> Ok I have no idea how this could happen. Can you mount -o clear_cache
> and see if it's just the cache that's bad? Thanks,
Did that and got this (it's a never ending story, this is from a F16
alpha boot cd hence stack trace could be
On 09/23/2011 08:55 AM, Mathieu Chouquet-Stringer wrote:
> On Thu, Sep 22, 2011 at 10:32:13PM +0200, Mathieu Chouquet-Stringer wrote:
>> On Thu, Sep 22, 2011 at 09:30:07PM +0200, Mathieu Chouquet-Stringer wrote:
>>> On Thu, Sep 22, 2011 at 03:00:03PM -0400, Josef Bacik wrote:
Oh wow sorry I se
The maximum number of dirty pages that exist in the system at any time
is determined by a number of pages considered dirtyable and a
user-configured percentage of those, or an absolute number in bytes.
This number of dirtyable pages is the sum of memory provided by all
the zones in the system minu
On Thu, Sep 22, 2011 at 10:52:42AM +0200, Johannes Weiner wrote:
> On Wed, Sep 21, 2011 at 04:02:26PM -0700, Andrew Morton wrote:
> > Should we rename determine_dirtyable_memory() to
> > global_dirtyable_memory(), to get some sense of its relationship with
> > zone_dirtyable_memory()?
>
> Sounds g
The amount of dirtyable pages should not include the full number of
free pages: there is a number of reserved pages that the page
allocator and kswapd always try to keep free.
The closer (reclaimable pages - dirty pages) is to the number of
reserved pages, the more likely it becomes for reclaim to
On Fri, 2011-09-23 at 16:03 +0300, Grazvydas Ignotas wrote:
> On Thu, Sep 22, 2011 at 11:18 PM, Alex Elder wrote:
> > On Mon, 2011-09-12 at 03:19 +0300, Grazvydas Ignotas wrote:
> >> The test checks if no duplicate d_off values are returned and that
> >> those values are seekable to the right inod
Chris,
Now that you're back from vacation, I was wondering if you would be
able to provide a revised estimate on how long this will take. Also,
of the four parts, which will be necessary to correct a 'parent
transid verify failed' error?
Thank you for your time,
--Erik
On Thu, Aug 18, 2011 at 1:
On Thu, Sep 22, 2011 at 11:18 PM, Alex Elder wrote:
> On Mon, 2011-09-12 at 03:19 +0300, Grazvydas Ignotas wrote:
>> The test checks if no duplicate d_off values are returned and that
>> those values are seekable to the right inodes.
>>
>> Signed-off-by: Grazvydas Ignotas
>
> I have two minor com
On Thu, Sep 22, 2011 at 10:32:13PM +0200, Mathieu Chouquet-Stringer wrote:
> On Thu, Sep 22, 2011 at 09:30:07PM +0200, Mathieu Chouquet-Stringer wrote:
> > On Thu, Sep 22, 2011 at 03:00:03PM -0400, Josef Bacik wrote:
> > > Oh wow sorry I sent you the completely wrong patch, I wish I had caught
> >
18 matches
Mail list logo
