disk-io.c: In function ‘btrfs_read_dev_super’:
disk-io.c:1217: warning: ‘ret’ may be used uninitialized in this function
Signed-off-by: Anand Jain anand.j...@oracle.com
---
disk-io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/disk-io.c b/disk-io.c
index 142197a..d10d647
Signed-off-by: Anand Jain anand.j...@oracle.com
---
mkfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mkfs.c b/mkfs.c
index 52b9a8d..cba4f02 100644
--- a/mkfs.c
+++ b/mkfs.c
@@ -1336,8 +1336,8 @@ int main(int ac, char **av)
case 'b':
mkfs cut of size '1024 * 1024 * 1024' to mark dev as small volume so to
force mixed group. Use a define for that.
Signed-off-by: Anand Jain anand.j...@oracle.com
---
mkfs.c | 2 +-
utils.c | 4 ++--
utils.h | 1 +
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/mkfs.c b/mkfs.c
When the added disk is small, the function btrfs_prepare_device() would
print message indicating that mixed group is forced, apparently thats
not true
reproducer:
mkfs.btrfs -f -draid1 -mraid1 /dev/sdd /dev/sdc
::
SMALL VOLUME: forcing mixed metadata/data groups WRONG
mount /dev/sdd /btrfs
Hello!
This is with 3.16-rc4 – stepped back to this one after having two hangs in one
day with 3.16-rc5, see other thread started by me:
martin@merkaba:~/Zeit/undeletable/db_data ls -lid akonadi
450598 drwx-- 1 martin martin 1232 Jun 22 14:11 akonadi
xfstests generic/127 detected this problem.
With commit 7fc34a62ca4434a79c68e23e70ed26111b7a4cf8, now fsync will only flush
data within the passed range. This is the cause of the above problem,
-- btrfs's fsync has a stage called 'sync log' which will wait for all the
ordered extents it've
On 15. juli 2014 11:09, Martin Steigerwald wrote:
Hello!
This is with 3.16-rc4 – stepped back to this one after having two hangs in one
day with 3.16-rc5, see other thread started by me:
martin@merkaba:~/Zeit/undeletable/db_data ls -lid akonadi
450598 drwx-- 1 martin martin 1232 Jun 22
Thank you very much for your advice. It worked!
I verified that the superblocks 1 and 2 had similar information with
btrfs-show-super -i 1 /dev/sdc1 (and -i 2) and then with crossed
fingers:
btrfs-select-super -s 2 /dev/sdc1
which restored my btrfs filesystem.
Then I runned scrub. For future
Am Dienstag, 15. Juli 2014, 11:25:15 schrieb Torbjørn:
On 15. juli 2014 11:09, Martin Steigerwald wrote:
Hello!
This is with 3.16-rc4 – stepped back to this one after having two hangs in
one day with 3.16-rc5, see other thread started by me:
martin@merkaba:~/Zeit/undeletable/db_data
On Tue, 15 Jul 2014 11:42:05 constantine wrote:
Thank you very much for your advice. It worked!
Great!
I verified that the superblocks 1 and 2 had similar information with
btrfs-show-super -i 1 /dev/sdc1 (and -i 2) and then with crossed
fingers:
btrfs-select-super -s 2 /dev/sdc1
which
On Tue, Jul 15, 2014 at 11:09:53AM +0200, Martin Steigerwald wrote:
Hello!
This is with 3.16-rc4 – stepped back to this one after having two hangs in
one
day with 3.16-rc5, see other thread started by me:
martin@merkaba:~/Zeit/undeletable/db_data ls -lid akonadi
450598 drwx-- 1
On Tue, 15 Jul 2014 17:31:14 +0800, Liu Bo wrote:
xfstests generic/127 detected this problem.
With commit 7fc34a62ca4434a79c68e23e70ed26111b7a4cf8, now fsync will only
flush
data within the passed range. This is the cause of the above problem,
-- btrfs's fsync has a stage called 'sync
unsubscribe
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jul 15, 2014 at 06:22:10PM +0800, Miao Xie wrote:
On Tue, 15 Jul 2014 17:31:14 +0800, Liu Bo wrote:
xfstests generic/127 detected this problem.
With commit 7fc34a62ca4434a79c68e23e70ed26111b7a4cf8, now fsync will only
flush
data within the passed range. This is the cause of
All the filesystems created and used below have 4k blocksize. The
file.bin file mentioned below is 8k in size and has two 4k
extents. The test program used can be found at http://fpaste.org/118057/.
1. First run (file range being passed is on block boundaries).
,
| [root@guest0 btrfs]#
On Tue, Jul 15, 2014 at 04:20:29PM +0630, Chandan Rajendra wrote:
All the filesystems created and used below have 4k blocksize. The
file.bin file mentioned below is 8k in size and has two 4k
extents. The test program used can be found at http://fpaste.org/118057/.
1. First run (file range
On 07/14/2014 05:58 PM, Martin Steigerwald wrote:
Am Montag, 14. Juli 2014, 16:12:22 schrieb Chris Mason:
On 07/14/2014 11:10 AM, Martin Steigerwald wrote:
Am Montag, 14. Juli 2014, 17:04:22 schrieben Sie:
Hi!
While with 3.16-rc3 and rc4 I didn´t have a BTRFS hang in several days of
usage,
Hi there,
I noticed yesterday that the mount points on my btrfs RAID1 filesystem
had become read-only. On a reboot, the filesystem fails to mount. I
wondered if someone here might be able offer any advice on how to
recover (if possible) from this position?
dmesg is showing the following errors
On Tue, Jul 15, 2014 at 08:15:12AM -0400, Brian Foster wrote:
On Tue, Jul 15, 2014 at 04:20:29PM +0630, Chandan Rajendra wrote:
All the filesystems created and used below have 4k blocksize. The
file.bin file mentioned below is 8k in size and has two 4k
extents. The test program used can be
Am Dienstag, 15. Juli 2014, 09:21:40 schrieb Chris Mason:
On 07/14/2014 05:58 PM, Martin Steigerwald wrote:
Am Montag, 14. Juli 2014, 16:12:22 schrieb Chris Mason:
On 07/14/2014 11:10 AM, Martin Steigerwald wrote:
Am Montag, 14. Juli 2014, 17:04:22 schrieben Sie:
Hi!
While with
On Tuesday 15 Jul 2014 09:53:49 Brian Foster wrote:
On Tue, Jul 15, 2014 at 08:15:12AM -0400, Brian Foster wrote:
On Tue, Jul 15, 2014 at 04:20:29PM +0630, Chandan Rajendra wrote:
All the filesystems created and used below have 4k blocksize. The
file.bin file mentioned below is 8k in size
Hi,
I see that btrfs is using kernel workqueues since linux 3.15. After
some tests I noticed performance regressions with fs_mark.
mount options: rw,relatime,compress=lzo,space_cache
fs_mark on Kernel 3.14.9:
# fs_mark -d /mnt/btrfs/fsmark -D 512 -t 16 -n 4096 -s 51200 -L5 -S0
On 07/15/2014 11:26 AM, Morten Stevens wrote:
Hi,
I see that btrfs is using kernel workqueues since linux 3.15. After
some tests I noticed performance regressions with fs_mark.
mount options: rw,relatime,compress=lzo,space_cache
fs_mark on Kernel 3.14.9:
# fs_mark -d
Fix the following sparse warning:
fs/btrfs/send.c:518:51: warning: incorrect type in argument 2 (different
address spaces)
fs/btrfs/send.c:518:51:expected char const [noderef] asn:1*noident
fs/btrfs/send.c:518:51:got char *
We can safely use (const char __user *) with set_fs(KERNEL_DS)
Hi, the following patches try to fix a long outstanding issue with qgroups
and snapshot deletion. The core problem is that btrfs_drop_snapshot will
skip shared extents during it's tree walk. This results in an inconsistent
qgroup state once the drop is processed. We also have a bug where qgroup
We want this to debug qgroup changes on live systems.
Signed-off-by: Mark Fasheh mfas...@suse.de
Reviewed-by: Josef Bacik jba...@fb.com
---
fs/btrfs/qgroup.c| 3 +++
fs/btrfs/super.c | 1 +
include/trace/events/btrfs.h | 56
During its tree walk, btrfs_drop_snapshot() will skip any shared
subtrees it encounters. This is incorrect when we have qgroups
turned on as those subtrees need to have their contents
accounted. In particular, the case we're concerned with is when
removing our snapshot root leaves the subtree with
From: Josef Bacik jba...@fb.com
Before I extended the no_quota arg to btrfs_dec/inc_ref because I didn't
understand how snapshot delete was using it and assumed that we needed the
quota operations there. With Mark's work this has turned out to be not the
case, we _always_ need to use no_quota
btrfs_drop_snapshot() leaves subvolume qgroup items on disk after
completion. This wastes space and also can cause problems with snapshot
creation. If a new snapshot tries to claim the deleted subvolumes id,
btrfs will get -EEXIST from add_qgroup_item() and go read-only.
We can partially fix this
Hello,
I have a VirtualBox hard drive image which is quite fragmented even
after very light use; it is 1.6 GB in size and has around 5000 fragments
(I'm using filefrag to determine the number of fragments). Doing a
btrfs fi defrag -f image.vdi reduced the number of fragments to 3749.
Even
cc linux-btrfs list
On Tue, Jul 15, 2014 at 10:40:46PM +0900, Norbert Preining wrote:
Dear all
(please keep Cc)
Since 3.16-rc3 or so I regularly get btrfs hanging in some transations.
Usually during apt-get upgrade or some other large file operations
(cowbuilder building of packages).
From: Luis R. Rodriguez mcg...@suse.com
ustat() does not work for btrfs, the reason is the VFS layer
cannot get to the super block from the anonymous bdevs. The
way these are used within btrfs though are to actually use a
series of them per superblock. This modifies the way the
VFS exposes these
From: Luis R. Rodriguez mcg...@suse.com
Modern filesystems are using the get_anon_bdev() for
internal notions of volumes, snapshots for a single super block
but never exposing them directly to the VFS layer. While this
works its leaves the VFS layer growing dumb over what filesystems
are doing.
From: Luis R. Rodriguez mcg...@suse.com
Use the new VFS layer struct super_block_dev instead of carrying
the anonymous bdev's on our own. This makes the VFS layer aware of
all of our anonymous dev's on the super block.
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
fs/btrfs/ctree.h | 7
Hi
I'd just like to comment that I currently have the same problem, quota
are enabled, server can't stay up more than 15 days without hogging
all of its memory. Use case is a torrent server which has more read
than writes and a desktop. Kmemleak does not detect this leak after 10
days and at
Hi,
For this same problem I once got into single user after 2 weeks of
utilisation and killed all, umounted all FS except root which is ext4,
rmmod'ed all modules and see by yourself:
http://i39.tinypic.com/2rrrjtl.jpg
For those who want it textually:
15 days uptime
10 user mode processes
Since this patch:
btrfs-progs: move the check_argc_* functions into utils.c
All tools including the independent tools(e.g. btrfs-image, btrfs-convert)
can share the convenience of the check_argc_* functions, so this patch
adopt the argc check functions globally.
Signed-off-by: Gui
On Wed, 2014-07-16 at 11:44 +0800, Gui Hecheng wrote:
Oh, very sorry for the noise, this is not the new one, please *ignore*
this one.
And also, for you to check, the v1 patch makes 2 mistakes:
o mistakenly change the value of argc, which influence the following
procedures.
o
Since this patch:
btrfs-progs: move the check_argc_* functions into utils.c
All tools including the independent tools(e.g. btrfs-image, btrfs-convert)
can share the convenience of the check_argc_* functions, so this patch
adopt the argc check functions globally.
Signed-off-by: Gui
Before this patchset, btrfs has 2 different routine to handle subvolume mount:
1) subvol= routine
When subvol name is given by subvol= mount option, btrfs will mount the fs
and then use mount_subtree() to mount the subvolume.
This routine is good since vfs layer is aware of which subtree is
btrfs uses differnet routine to handle 'subvolid=' and 'subvol=' mount
option.
Given 'subvol=' mount option, btrfs will mount btrfs first and then call
mount_subtree() to mount a subtree of btrfs, making vfs handle the path
searching.
This is good since vfs layer know extactly that a subtree mount
Old btrfs codes do the default subvolume search in get_default_root(),
which makes default subvolume mount will not info vfs that it's a
subtree mount.
Now since btrfs_mount_subvol() will mount all btrfs subvolume throught
mount_subtree() vfs API, merge the default subvolume searching codes
into
Isn't this the problem again the btrfs uses different assignments for
st_dev than s_dev? I don't even want to think about a mess like this
before that is fixed.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More
43 matches
Mail list logo
