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

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

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

Hi - I''m trying btrfs with kernel 2.6.38.8-32.fc15.x86_64 (a Fedora kernel). I''m just doing a tar-to-tar copy onto the file system with compress- force=zlib. Here are some traces of the stuck processes. flush-btrfs-5 seems to be stuck: Jul 8 11:49:40 xback2 kernel: [74920.681032] flush-btrfs-5 D ffff88003c7bae60 0 11712 2 0x00000080 Jul 8 11:49:40 xback2 kernel:

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

Hello On my HP Compaq dc5800 with Ubuntu 13.04 and their 3.8.0-19-lowlatency kernel, I''ve got quite some kernel traces in the syslog. You can find them below or at http://pastebin.com/bLXPBX67 (to avoid line breaks…). These kernel traces all begin with: WARNING: at fs/btrfs/free-space-cache.c:921 __btrfs_write_out_cache+0x6b9/0x9a0 [btrfs]() Most of the time, it starts with: Call

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

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.

Hello btrfs! Recently I upgraded to 3.2.0-rc4 due to instabilities with my btrfs filesystem in 3.1.1. While with 3.1.1 my system completely froze, with 3.2.0-rc4 it stays at least somehow usable (for some strange reason my xorg screen turns black as soon as this happens, only ssh is working then). Scrubbing reports 1 uncorrectable error. I have this error since my system froze due to some

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 +++