I use btrfs on a SD card. When my computer is running in idle (i.e.
nothing running but wmii and a few background tasks that don't do any
i/o; freshly synced), from time to time some [btrfs-*] tasks do writes
(for 5 seconds or so). What are those processes doing on my disk,
having nothing to writ
On mon, 29 Aug 2011 02:45:07 +0100, Maciej Marcin Piechotka wrote:
> I receive the bug when I try to snapshot from fcron:
>
> 2011-08-29T02:00:46.529238+01:00 picard kernel: [ 4155.76]
> [ cut here ]
> 2011-08-29T02:00:46.529253+01:00 picard kernel: [ 4155.90] kerne
Sorry, I forgot unlocking inode before returning -EINVAL in the previous
patch, thanks Tao pointing this out!
From 1825149c67cbfe7cbafcee4156e1f301dade7b0b Mon Sep 17 00:00:00 2001
From: Jie Liu
Date: Tue, 30 Aug 2011 11:51:00 +0800
Subject: [PATCH 1/1] Return -EINVAL ranther than offset if off
From: Sergei Trofimovich
btrfs_print_leaf() is usually called in emergency situations.
Don't die on SIGSEGV in such situations. Skip gracefully instead:
> [ 18.68] parent transid verify failed on 227736236032 wanted 132659
> found 123593
> [ 22.41] btrfs: btrfs_print_leaf got NULL e
Hallo list,
I use btrfs on a SD card. When my computer is running in idle (i.e.
nothing running but wmii and a few background tasks that don't do any
i/o; freshly synced), from time to time some [btrfs-*] tasks do writes
(for 5 seconds or so). What are those processes doing on my disk,
havin
> > [ 282.380849] [ cut here ]
> > [ 282.380865] WARNING: at fs/inode.c:1315 iput+0x20b/0x210()
> > [ 282.380869] Hardware name: HP Compaq 2510p Notebook PC
> > [ 282.380873] Modules linked in: ext2 loop kvm_intel kvm fuse
> > scsi_wait_scan usb_storage tun i915 drm_kms
A debugging helper, not really intended for merge.
From: David Sterba
Signed-off-by: David Sterba
---
fs/btrfs/extent-tree.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 44a3107..c5c1e7d 100644
--- a/fs/b
In moving some enospc stuff around I noticed that when we unmount we are often
evicting the free space cache inodes before we do our last commit. This isn't
bad, but it makes us constantly have to re-read the inodes back. So instead
don't evict the cache until after we do our last commit, this wi
On 08/29/2011 11:19 AM, Josef Bacik wrote:
> In tracking down this "not enough space" warning with checksums, it seems that
> we were running out of space partly because we do not reserve space for our
> free
> space inodes. Since this is technically metadata anyway go ahead and use the
> global_
In tracking down this "not enough space" warning with checksums, it seems that
we were running out of space partly because we do not reserve space for our free
space inodes. Since this is technically metadata anyway go ahead and use the
global_block_rsv for our free space inodes. We shouldn't be
In tracking down this "not enough space" warning with checksums, it seems that
we were running out of space partly because we do not reserve space for our free
space inodes. Since this is technically metadata anyway go ahead and use the
global_block_rsv for our free space inodes. We shouldn't be
While debugging a different issue I noticed that we were always reserving space
when we tried to use our truncate block rsv's. This is because they didn't have
a ->size value, so use_block_rsv just assumes there is nothing reserved and it
does a reserve_metadata_bytes. This is because btrfs_check
Hello,
in btrfs_ioctl_clone(), using u32 for super_block->s_blocksize assignment.
Signed-off-by: Jie Liu
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 970977a..03ab77a 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2133,12 +2133,12 @@ static noinline long btrfs_ioctl_clone(s
Hello,
In btrfs_file_llseek(), if the offset < 0 or offset >
inode->i_sb->s_maxbytes, we should return -EINVAL rather than offset.
Also, if the offset >= inode->i_size for SEEK_DATA or SEEK_HOLE, return
-ENXIO is ok IMHO.
Signed-off-by: Jie Liu
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
14 matches
Mail list logo
