On Tue, Sep 20, 2011 at 03:45:14PM +0200, Johannes Weiner wrote:
> Tell the page allocator that pages allocated through
> grab_cache_page_write_begin() are expected to become dirty soon.
>
> Signed-off-by: Johannes Weiner
Reviewed-by: Minchan Kim
--
Kinds regards,
Minchan Kim
--
To unsubscribe
On Fri, Sep 23, 2011 at 04:41:07PM +0200, Johannes Weiner wrote:
> 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
On Fri, Sep 23, 2011 at 04:42:48PM +0200, Johannes Weiner wrote:
> 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.
It's explanation of old a
Hi Hannes,
On Fri, Sep 23, 2011 at 04:38:17PM +0200, Johannes Weiner wrote:
> 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 - dir
01:17, Artem worte:
> Hi!
>
> So, it makes sense to keep the compression on by default
> and with LZO many people are going there.
>
> But, I want to create a database on a compressed btrfs filesystem
> which is seek-heavy rather than throughput-heavy
> and I really want to turn the compression o
On 09/27/2011 11:02 PM, Josef Bacik wrote:
> Xfstests 79 was failing because we were inheriting the S_APPEND flag when we
> weren't supposed to. There isn't any specific documentation on this so I'm
> taking the test as the standard of how things work, and having S_APPEND set
> on a
> directory d
+1
2011/9/27 Jeff Putney :
> On Thu, Aug 18, 2011 at 3:50 PM, Chris Mason wrote:
>> I had hoped to get #1 out the door before I left on vacation and I still
>>might
>> post it tonight.
>>
>> -chris
>
> I don't think this is the honest time line that people were looking
> for. Instead of playing
On Tue, Sep 27, 2011 at 03:02:41PM +0200, David Sterba wrote:
> On Tue, Aug 23, 2011 at 11:01:48PM +0300, Ilya Dryomov wrote:
> > This allows to have a separate set of filters for each chunk type
> > (data,meta,sys). The code however is generic and switch on chunk type
> > is only done once.
> >
Hi!
So, it makes sense to keep the compression on by default
and with LZO many people are going there.
But, I want to create a database on a compressed btrfs filesystem
which is seek-heavy rather than throughput-heavy
and I really want to turn the compression off just for that database
(smaller I
On 09/27/2011 11:01 AM, David Sterba wrote:
> On Mon, Sep 26, 2011 at 05:36:32PM -0400, Josef Bacik wrote:
>> Btrfs: fix how we mount subvol=
>
> this patch was not sent to the mailiglist, although this is an
> intersting change from the user's POV:
>
> subvolumes are now mountable via
>
>
On 09/27/2011 10:44 AM, David Sterba wrote:
> On Mon, Sep 26, 2011 at 03:56:29PM -0400, Josef Bacik wrote:
>> I noticed while running xfstests 83 that if we didn't have enough space to
>> delete our inode the orphan cleanup would just loop. This is because it
>> keeps
>> finding the same orphan i
Xfstests 79 was failing because we were inheriting the S_APPEND flag when we
weren't supposed to. There isn't any specific documentation on this so I'm
taking the test as the standard of how things work, and having S_APPEND set on a
directory doesn't mean that S_APPEND gets inherited by its childr
On Mon, Sep 26, 2011 at 05:36:32PM -0400, Josef Bacik wrote:
> Btrfs: fix how we mount subvol=
this patch was not sent to the mailiglist, although this is an
intersting change from the user's POV:
subvolumes are now mountable via
-o subvol=any/path/always/relative/to/toplevel
which makes
On Mon, Sep 26, 2011 at 03:56:29PM -0400, Josef Bacik wrote:
> I noticed while running xfstests 83 that if we didn't have enough space to
> delete our inode the orphan cleanup would just loop. This is because it keeps
> finding the same orphan item and keeps trying to kill it but can't because we
On Thu, Aug 18, 2011 at 3:50 PM, Chris Mason wrote:
> I had hoped to get #1 out the door before I left on vacation and I still might
> post it tonight.
>
> -chris
I don't think this is the honest time line that people were looking
for. Instead of playing more guessing games, how about we just ge
On Mon, Sep 26, 2011 at 01:56:18PM -0400, Josef Bacik wrote:
> If I have a range where I know a certain bit is and I want to set it to
> another
> bit the only option I have is to call set and then clear bit, which will
> result
> in 2 tree searches. This is inefficient, so introduce convert_ext
On Tue, Aug 23, 2011 at 11:01:55PM +0300, Ilya Dryomov wrote:
> Introduce a new btree objectid for storing restripe item. The reason is
> to be able to resume restriper after a crash with the same parameters.
> Restripe item has a very high objectid and goes into tree of tree roots.
>
> The key f
On Tue, Aug 23, 2011 at 11:01:51PM +0300, Ilya Dryomov wrote:
> Select chunks that are less than X percent full.
>
> Signed-off-by: Ilya Dryomov
> ---
> fs/btrfs/volumes.c | 33 +
> fs/btrfs/volumes.h |1 +
> 2 files changed, 34 insertions(+), 0 deletions(-)
On Tue, Aug 23, 2011 at 11:01:48PM +0300, Ilya Dryomov wrote:
> This allows to have a separate set of filters for each chunk type
> (data,meta,sys). The code however is generic and switch on chunk type
> is only done once.
>
> This commit also adds a type filter: it allows to balance for example
On Tue, Aug 23, 2011 at 11:01:42PM +0300, Ilya Dryomov wrote:
> {data,metadata,system}_alloc_profile fields have been unused for a long
> time now. Get rid of them.
a good cleanup which could be sent separately.
d/
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the b
Hi,
I've hit a problem with restriper but under ragher unclear conditions:
[12308.210636] [ cut here ]
[12308.214185] kernel BUG at fs/btrfs/relocation.c:2047!
[12308.214185] invalid opcode: [#1] SMP
[12308.214185] CPU 0
[12308.214185] Modules linked in: loop btrfs ao
2011-09-27 10:15:09 +0100, Stephane Chazelas:
[...]
> a btrfs file system of mine started to behave very poorly with
> some btrfs kernel tasks taking 100% of CPU time.
>
> # btrfs fi show /dev/sdb
> Label: none uuid: b3ce8b16-970e-4ba8-b9d2-4c7de270d0f1
> Total devices 3 FS bytes used 4.2
Hiya,
Recently,
a btrfs file system of mine started to behave very poorly with
some btrfs kernel tasks taking 100% of CPU time.
# btrfs fi show /dev/sdb
Label: none uuid: b3ce8b16-970e-4ba8-b9d2-4c7de270d0f1
Total devices 3 FS bytes used 4.25TB
devid2 size 2.73TB used 1.52T
On 09/27/2011 10:52 AM, Jim wrote:
> Hi Btrfs list,
> I am testing btrfs on a (to me) large filesystem. The tree consists of
> /data/sites/...0419/email.addr/files.
> Within each of the 420 directories are 2562 directories each with 20
> files on average. The files range from
> small html fil
24 matches
Mail list logo
