Problems with tuxonice and btrfs
I get filesystem corruption when I unsuccessfully hibernate using tuxonice. I don't get this problem using standard suspend. While I understand TOI is not in mainline it requires no modification for non-FUSE filesystems. where should I report the problem? Best regards signature.asc Description: This is a digitally signed message part
Snapshot of root makes an undeletable folder
I recently converted a long-used ext4 filesystem after e2fsck to btrfs using btrfs-convert, everything went fine and all my files are there. I then decided to make the filesystem more managable so I made a snapshot of the root and removed the rest of the root like: Original listing: ext2_saved folder1 folder2 folder3 folder4 lost+found btrfs sub snap . music rm -rf folder1 folder2 folder3 folder4 lost+found music/lost+found So now I end up with only a music folder on root which I was able to mount using subvol= to another folder and use the btrfs FS for other subvolumes. The next day I decided to remove the ext2_image snapshot and grow the filesystem to accomodate for other files, this was still OK. Then I though about my folder organization again and renamed music to downloads, this is still OK and then create music in downloads, I was told music already exists, however I can't neither see it, list it, cd to it or remove it. I then made a snapshot of downloads to music and now music is listed as: ls: cannot access /mnt/btrfs/downloads/music: No such file or directory d? ? ? ? ?? music btrfsck gives me: root /mnt # btrfsck /dev/vgP4RAID5/btrfs root 289 root dir 256 error found 52167258112 bytes used err is 1 total csum bytes: 50868244 total tree bytes: 76210176 total fs tree bytes: 6860800 btree space waste bytes: 15322691 file data blocks allocated: 52091047936 referenced 52091047936 Btrfs v0.19-35-g1b444cd-dirty There is also a OOPS associated to it: [82291.652513] new size for /dev/mapper/vgP4RAID5-btrfs is 75161927680 [83636.560865] btrfs failed to delete reference to music, inode 263 parent 256 [83679.232134] [ cut here ] [83679.232142] WARNING: at fs/dcache.c:1350 d_set_d_op+0x8e/0xc0() [83679.232144] Hardware name: P55-USB3 [83679.232145] Modules linked in: snd_seq_dummy snd_seq snd_seq_device nvidia(P) squashfs xfs exportfs reiserfs ext3 jbd snd_hda_codec_realtek usbhid snd_hda_intel snd_hda_codec hid usblp snd_hwdep snd_pcm sg i2c_i801 intel_agp snd_timer snd evdev ppdev parport_pc soundcore snd_page_alloc i2c_core r8169 intel_gtt parport mii processor pcspkr iTCO_wdt iTCO_vendor_support button ipv6 sr_mod sd_mod cdrom pata_acpi pata_jmicron ahci libahci libata uhci_hcd xhci_hcd btrfs zlib_deflate crc32c libcrc32c ext4 mbcache jbd2 crc16 fuse usb_storage scsi_mod ehci_hcd usbcore raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 md_mod dm_snapshot dm_mod loop [83679.232186] Pid: 14614, comm: ls Tainted: P3.0.4-Ti #2 [83679.232187] Call Trace: [83679.232193] [8105c7ef] warn_slowpath_common+0x7f/0xc0 [83679.232195] [8105c84a] warn_slowpath_null+0x1a/0x20 [83679.232196] [8116bdfe] d_set_d_op+0x8e/0xc0 [83679.232199] [8117c50f] simple_lookup+0x3f/0x60 [83679.232201] [811626f5] d_alloc_and_lookup+0x45/0x90 [83679.232204] [8116f765] ? d_lookup+0x35/0x60 [83679.232206] [81163f5e] do_lookup+0x29e/0x310 [83679.232208] [81164bdc] path_lookupat+0x11c/0x700 [83679.232210] [811651f1] do_path_lookup+0x31/0xc0 [83679.232211] [81166db9] user_path_at+0x59/0xa0 [83679.232214] [812b871b] ? tty_ioctl+0x5cb/0xbc0 [83679.232217] [810398f0] ? do_page_fault+0x1c0/0x4d0 [83679.232220] [8115c284] vfs_fstatat+0x44/0x70 [83679.232224] [81072f0d] ? do_sigaction+0x12d/0x1f0 [83679.232226] [8115c2eb] vfs_stat+0x1b/0x20 [83679.232227] [8115c42a] sys_newstat+0x1a/0x40 [83679.232229] [810732dd] ? sys_rt_sigaction+0x8d/0xc0 [83679.232233] [813f4485] ? page_fault+0x25/0x30 [83679.232267] [813f4a42] system_call_fastpath+0x16/0x1b [83679.232269] ---[ end trace 6bdc8b9bb849be1c ]--- [83679.232270] [ cut here ] [83679.232272] WARNING: at fs/dcache.c:1354 d_set_d_op+0xb1/0xc0() [83679.232273] Hardware name: P55-USB3 [83679.232274] Modules linked in: snd_seq_dummy snd_seq snd_seq_device nvidia(P) squashfs xfs exportfs reiserfs ext3 jbd snd_hda_codec_realtek usbhid snd_hda_intel snd_hda_codec hid usblp snd_hwdep snd_pcm sg i2c_i801 intel_agp snd_timer snd evdev ppdev parport_pc soundcore snd_page_alloc i2c_core r8169 intel_gtt parport mii processor pcspkr iTCO_wdt iTCO_vendor_support button ipv6 sr_mod sd_mod cdrom pata_acpi pata_jmicron ahci libahci libata uhci_hcd xhci_hcd btrfs zlib_deflate crc32c libcrc32c ext4 mbcache jbd2 crc16 fuse usb_storage scsi_mod ehci_hcd usbcore raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 md_mod dm_snapshot dm_mod loop [83679.232309] Pid: 14614, comm: ls Tainted: PW 3.0.4-Ti #2 [83679.232310] Call Trace: [83679.232313] [8105c7ef] warn_slowpath_common+0x7f/0xc0 [83679.232316] [8105c84a] warn_slowpath_null+0x1a/0x20 [83679.232318] [8116be21] d_set_d_op+0xb1/0xc0 [83679.232321] [8117c50f] simple_lookup+0x3f/0x60
Re: hang on 'echo 3 /proc/sys/vm/drop_caches'
On Sun, 4 Sep 2011 18:17:23 +0300
Sergei Trofimovich sly...@gmail.com wrote:
Short prehistory.
I've noticed worrying dmesg message today:
[26258.950593] btrfs csum failed ino 5360433 off 262144 csum 3995556063
private 3831717007
'find / -inum 5360433' helped me to find the file out:
/usr/lib64/libasound.so.2.0.0
I didn't modify it since 18.08.2011
I've tried to verify file's checksum against one stored in
package database and found out file is not corrupted.
So the error is an HDD glitch (or some memory corruption in btrfs code?)
I've attempted to drop caches and got a hangup:
# echo 3 /proc/sys/vm/drop_caches
And now the bash process eats 100% CPU.
After seemingly clean reboot (/sbin/reboot didn't hang, rebooted fine)
I've got corrupted filesystem (or it was corrupted earlier, but I didn't
notice):
[ 39.410962] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control:
Rx/Tx
[ 39.410972] e1000e :00:19.0: eth0: 10/100 speed: disabling TSO
[ 112.639689] BUG: sleeping function called from invalid context at
mm/slub.c:1004
[ 112.639697] in_atomic(): 1, irqs_disabled(): 0, pid: 2224, name: mc
[ 112.639703] 2 locks held by mc/2224:
[ 112.639707] #0: (sb-s_type-i_mutex_key#3){+.+.+.}, at:
[810ecb99] do_lookup+0x239/0x380
[ 112.639729] #1: (#12){..}, at: [811f5cc0]
btrfs_clear_lock_blocking_rw+0x30/0xc0
[ 112.639750] Pid: 2224, comm: mc Not tainted 3.1.0-rc4-00082-g26e254e #150
[ 112.639754] Call Trace:
[ 112.639765] [8103424f] __might_sleep+0xef/0x120
[ 112.639773] [810d8753] kmem_cache_alloc+0xc3/0xe0
[ 112.639781] [811e3317] alloc_extent_state+0x17/0x60
[ 112.639789] [811e5467] set_extent_bit+0x3a7/0x5f0
[ 112.639797] [8109db5e] ? wait_on_page_bit+0x6e/0x80
[ 112.639805] [811e5820] lock_extent_bits+0x80/0xb0
[ 112.639814] [811c0862] verify_parent_transid+0x82/0x160
[ 112.639821] [811c0a9b] btrfs_buffer_uptodate+0x4b/0x70
[ 112.639830] [811a7874] read_block_for_search+0x164/0x3e0
[ 112.639837] [811a7095] ? generic_bin_search+0xf5/0x180
[ 112.639846] [811ad47e] btrfs_search_slot+0x35e/0x890
[ 112.639852] [810347e1] ? get_parent_ip+0x11/0x50
[ 112.639860] [811bf30a] btrfs_lookup_inode+0x2a/0xa0
[ 112.639868] [811ce7c8] btrfs_iget+0x118/0x4a0
[ 112.639876] [81455ff0] ? _raw_spin_unlock+0x30/0x60
[ 112.639884] [811d4b83] btrfs_lookup_dentry+0x4a3/0x4f0
[ 112.639891] [810f6400] ? d_validate+0x60/0xb0
[ 112.639898] [81454356] ? mutex_lock_nested+0x2a6/0x3a0
[ 112.639905] [811d4be1] btrfs_lookup+0x11/0x30
[ 112.639913] [810ec10c] d_inode_lookup+0x1c/0x50
[ 112.639920] [810ecc59] do_lookup+0x2f9/0x380
[ 112.639928] [810ee704] path_lookupat+0x144/0x750
[ 112.639936] [810b7d8e] ? might_fault+0x4e/0xa0
[ 112.639944] [810eed3e] do_path_lookup+0x2e/0x80
[ 112.639951] [810eee64] user_path_at+0x54/0xa0
[ 112.639960] [81100323] ? vfsmount_lock_local_unlock+0x43/0x70
[ 112.639967] [810e6273] ? cp_new_stat+0xf3/0x110
[ 112.639974] [810e6107] vfs_fstatat+0x47/0x80
[ 112.639981] [810e6159] vfs_lstat+0x19/0x20
[ 112.639988] [810e62ff] sys_newlstat+0x1f/0x50
[ 112.639995] [81255f0e] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 112.640047] [81456afb] system_call_fastpath+0x16/0x1b
[ 112.640196] parent transid verify failed on 167391232 wanted 23923 found
38663
[ 112.640253] parent transid verify failed on 167391232 wanted 23923 found
38663
[ 112.640276] parent transid verify failed on 167391232 wanted 23923 found
38663
and now getting OOpses after short period of work. btrfsck reports missing
blocks.
--
Sergei
signature.asc
Description: PGP signature
Re: [PATCH] Fix -Wunused-but-set-variable warnings from GCC 4.6
On Mon, Aug 22, 2011 at 01:07:55PM +0100, Colin Watson wrote:
GCC 4.6 has a new -Wunused-but-set-variable warning category, enabled by
default by -Wall (http://gcc.gnu.org/gcc-4.6/changes.html), and since
btrfs-tools uses -Werror by default, this causes the build to fail. The
following patch fixes that. I believe all the code I removed is
provably a no-op, but of course it would be worth double-checking.
I think that all of this is fixed in the integration tree, I'm
afraid. I've certainly merged several gcc-4.6 fixes into the
integration branch over the last few months, and it seems to compile
happily with gcc-4.6 here.
Hugo.
Signed-off-by: Colin Watson cjwat...@ubuntu.com
---
btrfs-map-logical.c |2 --
btrfsck.c | 16 +++-
ctree.c | 16
debug-tree.c|2 ++
dir-item.c |7 +++
disk-io.c |4
extent-cache.c |5 +
extent-tree.c |6 ++
extent_io.c |4
mkfs.c |2 --
print-tree.c|3 ---
utils.c |3 +--
volumes.c |4
13 files changed, 20 insertions(+), 54 deletions(-)
diff --git a/btrfs-map-logical.c b/btrfs-map-logical.c
index a109c6a..8a12074 100644
--- a/btrfs-map-logical.c
+++ b/btrfs-map-logical.c
@@ -41,7 +41,6 @@ struct extent_buffer *debug_read_block(struct btrfs_root
*root, u64 bytenr,
u32 blocksize, int copy)
{
int ret;
- int dev_nr;
struct extent_buffer *eb;
u64 length;
struct btrfs_multi_bio *multi = NULL;
@@ -53,7 +52,6 @@ struct extent_buffer *debug_read_block(struct btrfs_root
*root, u64 bytenr,
if (!eb)
return NULL;
- dev_nr = 0;
length = blocksize;
while (1) {
ret = btrfs_map_block(root-fs_info-mapping_tree, READ,
diff --git a/btrfsck.c b/btrfsck.c
index 63e44d1..0c5f7fe 100644
--- a/btrfsck.c
+++ b/btrfsck.c
@@ -995,7 +995,6 @@ static int process_one_leaf(struct btrfs_root *root,
struct extent_buffer *eb,
struct btrfs_key key;
u32 nritems;
int i;
- int ret;
struct cache_tree *inode_cache;
struct shared_node *active_node;
@@ -1021,17 +1020,17 @@ static int process_one_leaf(struct btrfs_root *root,
struct extent_buffer *eb,
switch (key.type) {
case BTRFS_DIR_ITEM_KEY:
case BTRFS_DIR_INDEX_KEY:
- ret = process_dir_item(eb, i, key, active_node);
+ process_dir_item(eb, i, key, active_node);
break;
case BTRFS_INODE_REF_KEY:
- ret = process_inode_ref(eb, i, key, active_node);
+ process_inode_ref(eb, i, key, active_node);
break;
case BTRFS_INODE_ITEM_KEY:
- ret = process_inode_item(eb, i, key, active_node);
+ process_inode_item(eb, i, key, active_node);
break;
case BTRFS_EXTENT_DATA_KEY:
- ret = process_file_extent(root, eb, i, key,
- active_node);
+ process_file_extent(root, eb, i, key,
+ active_node);
break;
default:
break;
@@ -1917,7 +1916,6 @@ static int check_owner_ref(struct btrfs_root *root,
struct btrfs_root *ref_root;
struct btrfs_key key;
struct btrfs_path path;
- int ret;
int level;
int found = 0;
@@ -1950,7 +1948,7 @@ static int check_owner_ref(struct btrfs_root *root,
btrfs_init_path(path);
path.lowest_level = level + 1;
- ret = btrfs_search_slot(NULL, ref_root, key, path, 0, 0);
+ btrfs_search_slot(NULL, ref_root, key, path, 0, 0);
if (buf-start == btrfs_node_blockptr(path.nodes[level + 1],
path.slots[level + 1]))
@@ -2539,10 +2537,10 @@ static int run_next_block(struct btrfs_root *root,
continue;
}
if (key.type == BTRFS_BLOCK_GROUP_ITEM_KEY) {
+#if 0
struct btrfs_block_group_item *bi;
bi = btrfs_item_ptr(buf, i,
struct btrfs_block_group_item);
-#if 0
fprintf(stderr,block group %Lu %Lu used %Lu ,
btrfs_disk_key_objectid(disk_key),
btrfs_disk_key_offset(disk_key),
diff --git a/ctree.c b/ctree.c
index f70e10c..12f1a55 100644
--- a/ctree.c
+++ b/ctree.c
@@ -262,7 +262,6 @@ int __btrfs_cow_block(struct btrfs_trans_handle *trans,
struct
Re: Snapshot of root makes an undeletable folder
On Sun, Sep 04, 2011 at 11:29:43AM -0400, Jérôme Poulin wrote: I recently converted a long-used ext4 filesystem after e2fsck to btrfs using btrfs-convert, everything went fine and all my files are there. I then decided to make the filesystem more managable so I made a snapshot of the root and removed the rest of the root like: Original listing: ext2_saved folder1 folder2 folder3 folder4 lost+found btrfs sub snap . music rm -rf folder1 folder2 folder3 folder4 lost+found music/lost+found So now I end up with only a music folder on root which I was able to mount using subvol= to another folder and use the btrfs FS for other subvolumes. The next day I decided to remove the ext2_image snapshot and grow the filesystem to accomodate for other files, this was still OK. Then I though about my folder organization again and renamed music to downloads, this is still OK and then create music in downloads, I was told music already exists, however I can't neither see it, list it, cd to it or remove it. This is because music directory actually exists. When you executed btrfs sub snap . music btrfs created music directory item in your default subvolume and *then* took a snapshot of the default subvolume with that music directory item already in it. Btrfs readdir skips references from the snapshot to itself, so you can't see it. Even though you renamed your snapshot to downloads, snapshot's contents still don't allow you to create a music directory in it. The correct way to do what you want is to create a subvolume music, and move folders from default to music. Then you can snapshot your newly created music subvolume in a clean way, rename it, etc. I then made a snapshot of downloads to music and now music is listed as: ls: cannot access /mnt/btrfs/downloads/music: No such file or directory d? ? ? ? ?? music What command and in what directory did you run to make a snapshot of downloads to music ? I can't reproduce this off-hand. btrfsck gives me: root /mnt # btrfsck /dev/vgP4RAID5/btrfs root 289 root dir 256 error found 52167258112 bytes used err is 1 total csum bytes: 50868244 total tree bytes: 76210176 total fs tree bytes: 6860800 btree space waste bytes: 15322691 file data blocks allocated: 52091047936 referenced 52091047936 Btrfs v0.19-35-g1b444cd-dirty There is also a OOPS associated to it: [82291.652513] new size for /dev/mapper/vgP4RAID5-btrfs is 75161927680 [83636.560865] btrfs failed to delete reference to music, inode 263 parent 256 [83679.232134] [ cut here ] [83679.232142] WARNING: at fs/dcache.c:1350 d_set_d_op+0x8e/0xc0() [83679.232144] Hardware name: P55-USB3 [83679.232145] Modules linked in: snd_seq_dummy snd_seq snd_seq_device nvidia(P) squashfs xfs exportfs reiserfs ext3 jbd snd_hda_codec_realtek usbhid snd_hda_intel snd_hda_codec hid usblp snd_hwdep snd_pcm sg i2c_i801 intel_agp snd_timer snd evdev ppdev parport_pc soundcore snd_page_alloc i2c_core r8169 intel_gtt parport mii processor pcspkr iTCO_wdt iTCO_vendor_support button ipv6 sr_mod sd_mod cdrom pata_acpi pata_jmicron ahci libahci libata uhci_hcd xhci_hcd btrfs zlib_deflate crc32c libcrc32c ext4 mbcache jbd2 crc16 fuse usb_storage scsi_mod ehci_hcd usbcore raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 md_mod dm_snapshot dm_mod loop [83679.232186] Pid: 14614, comm: ls Tainted: P3.0.4-Ti #2 [83679.232187] Call Trace: [83679.232193] [8105c7ef] warn_slowpath_common+0x7f/0xc0 [83679.232195] [8105c84a] warn_slowpath_null+0x1a/0x20 [83679.232196] [8116bdfe] d_set_d_op+0x8e/0xc0 [83679.232199] [8117c50f] simple_lookup+0x3f/0x60 [83679.232201] [811626f5] d_alloc_and_lookup+0x45/0x90 [83679.232204] [8116f765] ? d_lookup+0x35/0x60 [83679.232206] [81163f5e] do_lookup+0x29e/0x310 [83679.232208] [81164bdc] path_lookupat+0x11c/0x700 [83679.232210] [811651f1] do_path_lookup+0x31/0xc0 [83679.232211] [81166db9] user_path_at+0x59/0xa0 [83679.232214] [812b871b] ? tty_ioctl+0x5cb/0xbc0 [83679.232217] [810398f0] ? do_page_fault+0x1c0/0x4d0 [83679.232220] [8115c284] vfs_fstatat+0x44/0x70 [83679.232224] [81072f0d] ? do_sigaction+0x12d/0x1f0 [83679.232226] [8115c2eb] vfs_stat+0x1b/0x20 [83679.232227] [8115c42a] sys_newstat+0x1a/0x40 [83679.232229] [810732dd] ? sys_rt_sigaction+0x8d/0xc0 [83679.232233] [813f4485] ? page_fault+0x25/0x30 [83679.232267] [813f4a42] system_call_fastpath+0x16/0x1b [83679.232269] ---[ end trace 6bdc8b9bb849be1c ]--- [83679.232270] [ cut here ] [83679.232272] WARNING: at fs/dcache.c:1354 d_set_d_op+0xb1/0xc0() [83679.232273] Hardware name: P55-USB3 [83679.232274] Modules linked in: snd_seq_dummy snd_seq snd_seq_device nvidia(P) squashfs xfs
Re: [PATCH] Btrfs-progs: added btrfs filesystem label [label] [path] support V2
On 09/05/2011 01:03 AM, Hugo Mills wrote:
On Sat, Sep 03, 2011 at 11:11:36AM +0800, Jeff liu wrote:
在 2011-9-2，下午11:48， David Sterba 写道：
On Fri, Sep 02, 2011 at 09:13:34PM +0800, Jeff Liu wrote:
--- a/ioctl.h
+++ b/ioctl.h
@@ -140,6 +140,8 @@ struct btrfs_ioctl_space_args {
struct btrfs_ioctl_vol_args)
#define BTRFS_IOC_SCAN_DEV _IOW(BTRFS_IOCTL_MAGIC, 4, \
struct btrfs_ioctl_vol_args)
+#define BTRFS_IOC_FS_SETLABEL _IOW(BTRFS_IOCTL_MAGIC, 5, \
+ struct btrfs_ioctl_fs_label_args)
/* trans start and trans end are dangerous, and only for
* use by applications that know how to avoid the
* resulting deadlocks
well, it is an unassigned number, but a newly added features should IMHO
allocate greater than current max value, ie over 31 in coordination with
https://btrfs.wiki.kernel.org/index.php/Project_ideas#Development_notes.2C_please_read
table.
It sounds reasonable to allocate a greater value, could anyone please confirm
it?
I'd just take number 50 for yours -- Li can update his patches
later.
Thank you, I'll post a patch for this change later.
-Jeff
Hugo.
What's your ioctl range for online fsck?
--
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
