On Sat, May 21, 2011 at 05:00:50AM +0200, Andi Kleen wrote:
> On Fri, May 20, 2011 at 08:30:19PM -0400, Josef Bacik wrote:
> > On 05/20/2011 05:31 PM, Andi Kleen wrote:
> > >> Putting them at the end of the cache LRU instead of the head would allow
> > >> them to be dropped quickly under memory pr
I've made a little progress - compiled from the tmp branch of
btrfs-progs-unstable, and the unsupported feature error message goes
away. However, now I segfault when running any command after three
parent transid failures. Gdb gives me this:
Starting program: /home/xbmc/btrfs-progs-unstable/btrf
On Fri, May 20, 2011 at 08:30:19PM -0400, Josef Bacik wrote:
> On 05/20/2011 05:31 PM, Andi Kleen wrote:
> >> Putting them at the end of the cache LRU instead of the head would allow
> >> them to be dropped quickly under memory pressure.
> >
> > This still would fill up your memory for find /, p
On 05/20/2011 05:31 PM, Andi Kleen wrote:
>> Putting them at the end of the cache LRU instead of the head would allow
>> them to be dropped quickly under memory pressure.
>
> This still would fill up your memory for find /, potentially pushing
> out other stuff.
>
> -Andi
So these things are j
On 21.05.2011 01:05, Miguel Garrido wrote:
On Fri, May 20, 2011 at 12:35 PM, Tomasz Chmielewski wrote:
Nobody has a clue what makes btrfs run out of space when used with PostgreSQL,
even when there is plenty of free space left?
# df -h
FilesystemSize Used Avail Use% Mounted on
On Fri, May 20, 2011 at 12:35 PM, Tomasz Chmielewski wrote:
>
> Nobody has a clue what makes btrfs run out of space when used with
> PostgreSQL, even when there is plenty of free space left?
>
>
> # df -h
> Filesystem Size Used Avail Use% Mounted on
> /dev/sdb4 336G 257G
> Putting them at the end of the cache LRU instead of the head would allow them
> to be dropped quickly under memory pressure.
This still would fill up your memory for find /, potentially pushing
out other stuff.
-Andi
--
a...@linux.intel.com -- Speaking for myself only.
--
To unsubscribe from
On 2011-05-20, at 2:07 PM, Andi Kleen wrote:
> Josef Bacik writes:
>
>> Btrfs (and I'd venture most other fs's) stores its indexes in nice disk order
>> for readdir, but unfortunately in the case of anything that stats the files
>> in
>> order that readdir spits back (like oh say ls) that mean
Signed-off-by: Sergei Trofimovich
---
fs/btrfs/inode.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 7cd8ab0..72650ce 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -1310,7 +1310,7 @@ static int btrfs_set_bit_hook(st
Signed-off-by: Sergei Trofimovich
---
fs/btrfs/dir-item.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/dir-item.c b/fs/btrfs/dir-item.c
index c62f02f..dec9348 100644
--- a/fs/btrfs/dir-item.c
+++ b/fs/btrfs/dir-item.c
@@ -452,7 +452,7 @@ int verify_dir_item(s
Observed as a large delay when --mixed filesystem is filled up.
Test example:
1. create tiny --mixed FS:
$ dd if=/dev/zero of=2G.img seek=$((2048 * 1024 * 1024 - 1)) count=1 bs=1
$ mkfs.btrfs --mixed 2G.img
$ mount -oloop 2G.img /mnt/ut/
2. Try to fill it up:
$ dd if=/dev/urandom of=10M
The really interesting commit is
btrfs: don't spin in shrink_delalloc if there is nothing to free
which fixes hogs on ENOSPC for me.
The rest of patches are cleanup.
Change since v2:
- Rebased against 2.6.39
Change since v1:
- Added Josef's Reviewed-by
- Fixed my MTA and patch numbering
Th
Josef Bacik writes:
> Btrfs (and I'd venture most other fs's) stores its indexes in nice disk order
> for readdir, but unfortunately in the case of anything that stats the files in
> order that readdir spits back (like oh say ls) that means we still have to do
> the normal lookup of the file, whi
Btrfs (and I'd venture most other fs's) stores its indexes in nice disk order
for readdir, but unfortunately in the case of anything that stats the files in
order that readdir spits back (like oh say ls) that means we still have to do
the normal lookup of the file, which means looking up our other
In btrfs we have 2 indexes for inodes. One is for readdir, it's in this nice
sequential order and works out brilliantly for readdir. However if you use ls,
it usually stat's each file it gets from readdir. This is where the second
index comes in, which is based on a hash of the name of the file.
On 16.05.2011 20:08, Tomasz Chmielewski wrote:
> The kernel used was 2.6.39-rc5.
>
> If it matters, I had the filesystem mounted with compress-force flag:
Nobody has a clue what makes btrfs run out of space when used with PostgreSQL,
even when there is plenty of free space left?
# df -h
Files
On 05/20/2011 07:52 AM, David Sterba wrote:
> On Wed, May 18, 2011 at 11:29:14AM +0800, Li Dongyang wrote:
>> Thanks for the fix, I thought EOPNOTSUPP could be useful by the caller
>> that time, and maybe we could do somthing like remove the discard
>> mount_opt in the fs_info so we can avoid calli
After upgrading from 2.6.39-rc7 to 2.6.39 this morning, I tried to
mount my 3 disk btrfs volume (no subvolumes, space caching enabled,
lzo compression) and received some parent transid errors (going back
to rc7 didn't help, though):
btrfs: disk space caching is enabled
parent transid verify failed
On Fri, May 20, 2011 at 7:22 AM, Chris Mason wrote:
> Once enabled it does stay on, and strictly speaking it does change the
> disk format. But, it is perfectly safe to go back to a non-space_cache
> enabled kernel and then go back into space cache. Josef set things up
> so it would detect a non
On Wed, May 18, 2011 at 11:29:14AM +0800, Li Dongyang wrote:
> Thanks for the fix, I thought EOPNOTSUPP could be useful by the caller
> that time, and maybe we could do somthing like remove the discard
> mount_opt in the fs_info so we can avoid calling it again.
I do not agree that discard should
Excerpts from Chester's message of 2011-05-20 01:32:22 -0400:
> >
> > Out of curiosity, why isn't this done automatically as opposed to
> > having to mount with the space_cache option?
>
> The space_cache option changes the disk format. Once enabled, it will
> be permanent. The mount option gives
Hi,
On Thu, May 19, 2011 at 02:19:08PM +0900, Tsutomu Itoh wrote:
> Currently, btrfs_truncate_item and btrfs_extend_item returns only 0.
> So, the check by BUG_ON in the caller is unnecessary.
well, I don't think it's right to remove the BUG_ONs right now.
btrfs_extend_item has it's own BUG_ON()s
22 matches
Mail list logo
