similar to: BTRFS warnings on the tons-of-symlinks operations

This uses uintptr_t to cast pointers to u64 ioctl arguments to silence some 32bit build warnings: cmds-inspect.c: In function ‘__ino_to_path_fd’: cmds-inspect.c:47:15: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] cmds-inspect.c: In function ‘cmd_logical_resolve’: cmds-inspect.c:171:15: warning: cast from pointer to integer of different size

When building on ppc64 I hit a number of warnings in printf: btrfs-map-logical.c:69: error: format ‘%Lu’ expects type ‘long long unsigned int’, but argument 4 has type ‘u64’ Fix them. Signed-off-by: Anton Blanchard <anton@samba.org> --- diff --git a/btrfs-list.c b/btrfs-list.c index 93766a8..c602b87 100644 --- a/btrfs-list.c +++ b/btrfs-list.c @@ -249,7 +249,8 @@ static int

From: Wade Cline <clinew@linux.vnet.ibm.com> The kernel uses unsigned long long for u64, but PPC64 uses unsigned long by default. This results in print warnings such as: print-tree.c:333: warning: format ‘%llu’ expects type ‘long long unsigned int’, but argument 4 has type ‘u64’ Defining __KERNEL__ before the file <asm/types.h>, or any file that includes this file, will let PPC64

I''m using Btrfs v0.20-rc1-253-g7854c8b on kernel 3.10.10-1-ARCH. I''ve been using this btrfs filesystem on an SSD for a little under a year with no problems until now. I noticed it was getting a bit full (~79%) and tried to do some cleanup by removing old snapshots. Immediately after, the filesystem went into read only mode. I then followed Hugo Mill''s advice (that was

when used Posix File System Test Suite(pjd-fstest) to test btrfs, some cases about setfacl failed when noacl mount option used. I simplified used commands in pjd-fstest, and the following steps can reproduce it. ------------------------ # cd btrfs-part/ # mkdir aaa # setfacl -m m::rw aaa <- successed, but not expected by pjd-fstest. ------------------------ I checked ext3, a warning

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I mentioned a ghost file. Here is the dump (less than 65M): http://dev.mccme.ru/~raskin/btrfs.dump ghost file is: 885dj1l4788pymp3bk2f3dz52ggcvw4v-empty/garbage-1/mwave.h.tmp-31838-1822528541 It has a name, but stat fails (so no inode, I guess). Also I can create another file with the same name in the directory. I cannot remove the file, or

tree: git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git master head: 0cb8658e96f1ba2ff2d730224cb31e231edd318d commit: 7017ac470ed5b029bc683883714a7f4a4ed34c33 Btrfs: move some common code into a subfunction date: 2 days ago config: make ARCH=x86_64 allyesconfig All warnings: fs/btrfs/volumes.c: In function ''btrfs_rm_device'': fs/btrfs/volumes.c:1505:1:

mkfs.c: In function ‘is_ssd’: mkfs.c:1168:26: warning: ignoring return value of ‘blkid_devno_to_wholedisk’, declared with attribute warn_unused_result [-Wunused-result] blkid_devno_to_wholedisk(devno, wholedisk, sizeof(wholedisk), NULL); Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com> --- mkfs.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/mkfs.c

Hello everyone, I wasn't planning on sending out v0.4 until ENOSPC was fixed, but Frank Groeneveld narrowed down a bug with the file data checksumming code on highmem 32bit machines. Basically the way I was using cryptomgr made it incorrectly calculate checksums on highmem pages. So to simplify things, I've switched over to plain libcrc32c. Anyone running on a 32 bit with highmem is

Hello everyone, I wasn't planning on sending out v0.4 until ENOSPC was fixed, but Frank Groeneveld narrowed down a bug with the file data checksumming code on highmem 32bit machines. Basically the way I was using cryptomgr made it incorrectly calculate checksums on highmem pages. So to simplify things, I've switched over to plain libcrc32c. Anyone running on a 32 bit with highmem is

Users report that an extent map''s list is still linked when it''s actually going to be freed from cache. The story is that a) when we''re going to drop an extent map and may split this large one into smaller ems, and if this large one is flagged as EXTENT_FLAG_LOGGING which means that it''s on the list to be logged, then the smaller ems split from it will also be

Hi everyone, The master branch of the btrfs unstable tree: git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git master Has a collection of btrfs bug fixes. The three most important fixes here address crashes in the btrfs O_DIRECT code, add a migrate_page operation to avoid metadata corruption as btree pages go through migration, and fix up our NFS support. Otherwise we have

Yesterday, I compiled the new kernel 3.0rc1 from git, but I never successed to go over the point: "Removing old temporary files". Pressing control-c let me boot on, but the pc was the complete time on very high load. It took me minutes, just to reach the tty login - and again minutes after login in, that I had my shell and a prompt to enter something. The load was at that time beyond 10.

Hi all, It seems like there is a possible race on delalloc_bytes in btrfs in kernel 2.6.33.Please examine this issue and let me know if this is a problem or not.The race could occur between stat system call and writeback kernel thread. The lines are fs/btrfs/inode.c 5422 fs/btrfs/inode.c 1378 The stack traces are For file line fs/btrfs/inode.c 5422 btrfs_getattr+0x141/0x15e

Hi all, Did someone have met this problem before. When doing the tests, I hit the WARN_ON. Is this log make sense or someone had fixed the problem. If needed, I can supply the detail log and the testcase source file. Version: the latest codes at linus git tree. [ 2140.981293] use_block_rsv: 336 callbacks suppressed [ 2140.981295] ------------[ cut here ]------------ [ 2140.981308]

Hello. I am continuing my tests of BtrFS under a practical workload. Recently an incorrect poweroff (or maybe a small bug in BtrFS) caused a small data loss. The actual damage was non-existent. I used old branch, so maybe the relevant code is already improved. 1. Why btrfsck says "bad block" on that partition? What does it mean? My fist reaction was to use badblocks. It found no

Our code is not ready to cope with a sectorsize that''s not equal to PAGE_SIZE. It will lead to hanging-on while writing something. Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com> --- fs/btrfs/disk-io.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index 20196f4..b9866f2 100644 --- a/fs/btrfs/disk-io.c +++

I believe what I am going to write is a bug report. When I finaly did # btrfs send -v /mnt/adama-docs/backups/20130101-192722 | btrfs receive /mnt/tmp/backups to migrate btrfs from one partition layout to another. After a while system keeps saying that "Too many open files in system" and denies access to almost every command line tool. When I had access to iostat I confirmed the

Is this useful to anyone? Got this after a crash/reboot: if (block_rsv) { WARN_ON(block_rsv->size > 0); <<<<<<<<<<<<<<<<<<<<<< btrfs_free_block_rsv(root, block_rsv); } ------------[ cut here ]------------ WARNING: at fs/btrfs/inode.c:2165 btrfs_orphan_commit_root+0xcb/0xdf() Hardware name: 2429A78 Modules linked in:

Currently there are 3 different capitalisations of btrfs: used in printk()''s, BTRFS: (3 occurences), Btrfs: (1 occurence) and btrfs: (77 occurences). It''s best to have them all the same for consistency, so we canonicalise the two minority cases to btrfs:. Signed-off-by: Chris Samuel <chris@csamuel.org> --- fs/btrfs/disk-io.c | 4 ++-- fs/btrfs/inode.c | 4 ++-- 2