Replacing corrupted files/directories
Is there a recommended way to replace a corrupted file or directory on btrfs? The use case I'm thinking of is handling filesystem corruption by restoring only the corrupted files from backup. For a corrupted file, it seems like deleting the file and replacing it with the copy from the backup works, but I don't know if this is necessarily the best way - the nature of copy-on-write means that there's still corrupt data lying around on the filesystem, right? And for directories, it's tricky, because (afaik) there's no way to delete a directory without first walking it; not good if it's corrupted. I think this is probably also relevant to something like Ceph or CRFS, where redundancy exists, but isn't managed by btrfs directly. -- 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
btrfs crash
I got the following crash on one of my Ceph nodes this morning. I don't know how to reproduce it yet; I was just wondering if it was a known issue. This is with the latest kernel for Ubuntu 10.10. Nov 13 19:21:21 alpha kernel: [19432.396679] [ cut here ] Nov 13 19:21:22 alpha kernel: [19432.396732] WARNING: at /build/buildd/linux-2.6.35/fs/btrfs/extent-tree.c:5322 btrfs_alloc_free_block+0x1e7/0x430 [btrfs]() Nov 13 19:21:22 alpha kernel: [19432.396743] Hardware name: Nov 13 19:21:22 alpha kernel: [19432.396749] Modules linked in: nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc snd_hda_codec_realtek i915 snd_hda_intel drm_kms_helper snd_hda_codec snd_hwdep drm ppdev snd_pcm parport_pc snd_timer intel_agp psmouse i2c_algo_bit serio_raw led_class lp snd video soundcore agpgart output snd_page_alloc parport btrfs r8169 floppy mii zlib_deflate crc32c libcrc32c Nov 13 19:21:22 alpha kernel: [19432.396839] Pid: 1007, comm: cosd Not tainted 2.6.35-22-generic-pae #35-Ubuntu Nov 13 19:21:22 alpha kernel: [19432.396848] Call Trace: Nov 13 19:21:22 alpha kernel: [19432.396874] [c01527b2] warn_slowpath_common+0x72/0xa0 Nov 13 19:21:22 alpha kernel: [19432.396920] [f85515c7] ? btrfs_alloc_free_block+0x1e7/0x430 [btrfs] Nov 13 19:21:22 alpha kernel: [19432.396965] [f85515c7] ? btrfs_alloc_free_block+0x1e7/0x430 [btrfs] Nov 13 19:21:22 alpha kernel: [19432.396981] [c0152802] warn_slowpath_null+0x22/0x30 Nov 13 19:21:22 alpha kernel: [19432.397025] [f85515c7] btrfs_alloc_free_block+0x1e7/0x430 [btrfs] Nov 13 19:21:22 alpha kernel: [19432.397041] [c013a864] ? kmap_atomic+0x24/0x30 Nov 13 19:21:22 alpha kernel: [19432.397054] [c013a77c] ? kmap_atomic_prot+0x4c/0x110 Nov 13 19:21:22 alpha kernel: [19432.397064] [c013a814] ? kmap_atomic_prot+0xe4/0x110 Nov 13 19:21:22 alpha kernel: [19432.397106] [f853d46d] __btrfs_cow_block+0x14d/0x5e0 [btrfs] Nov 13 19:21:22 alpha kernel: [19432.397120] [c013a655] ? kunmap_atomic+0x55/0x70 Nov 13 19:21:22 alpha kernel: [19432.397163] [f853d9db] btrfs_cow_block+0xdb/0x1c0 [btrfs] Nov 13 19:21:22 alpha kernel: [19432.397210] [f8543221] btrfs_search_slot+0x2a1/0x530 [btrfs] Nov 13 19:21:22 alpha kernel: [19432.397261] [f8db] btrfs_lookup_inode+0x3b/0xb0 [btrfs] Nov 13 19:21:22 alpha kernel: [19432.397311] [f8560364] btrfs_update_inode+0x54/0x100 [btrfs] Nov 13 19:21:22 alpha kernel: [19432.397360] [f856483d] btrfs_truncate+0x1cd/0x230 [btrfs] Nov 13 19:21:22 alpha kernel: [19432.397376] [c01eb4b0] vmtruncate+0x30/0x40 Nov 13 19:21:22 alpha kernel: [19432.397423] [f8568d36] btrfs_setattr_size+0xc6/0x2d0 [btrfs] Nov 13 19:21:22 alpha kernel: [19432.397471] [f8568fc7] btrfs_setattr+0x87/0x90 [btrfs] Nov 13 19:21:22 alpha kernel: [19432.397488] [c0238203] notify_change+0x143/0x2f0 Nov 13 19:21:22 alpha kernel: [19432.397501] [c022bd3b] ? putname+0x2b/0x40 Nov 13 19:21:22 alpha kernel: [19432.397513] [c0221a42] do_truncate+0x62/0x90 Nov 13 19:21:22 alpha kernel: [19432.397527] [c030dd9a] ? security_path_truncate+0x3a/0x50 Nov 13 19:21:22 alpha kernel: [19432.397540] [c0221d37] do_sys_truncate+0x137/0x140 Nov 13 19:21:22 alpha kernel: [19432.397553] [c0221d56] sys_truncate64+0x16/0x20 Nov 13 19:21:22 alpha kernel: [19432.397566] [c05f00f4] syscall_call+0x7/0xb Nov 13 19:21:22 alpha kernel: [19432.397577] [c05f] ? _lock_kernel+0x20/0x8a Nov 13 19:21:22 alpha kernel: [19432.397586] ---[ end trace e8ea54bc05860e29 ]--- ...followed by... [19432.397661] [ cut here ] [19432.397792] kernel BUG at /build/buildd/linux-2.6.35/fs/btrfs/inode.c:6182! [19432.397977] invalid opcode: [#1] SMP [19432.398096] last sysfs file: /sys/module/nfsd/initstate [19432.398227] Modules linked in: nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc snd_hda_codec_realtek i915 snd_hda_intel drm_kms_helper snd_hda_codec snd_hwdep drm ppdev snd_pcm parport_pc snd_timer intel_agp psmouse i2c_algo_bit serio_raw led_class lp snd video soundcore agpgart output snd_page_alloc parport btrfs r8169 floppy mii zlib_deflate crc32c libcrc32c [19432.399458] [19432.399509] Pid: 1007, comm: cosd Tainted: GW 2.6.35-22-generic-pae #35-Ubuntu LakePort/ [19432.399746] EIP: 0060:[f8564893] EFLAGS: 00010286 CPU: 0 [19432.399937] EIP is at btrfs_truncate+0x223/0x230 [btrfs] [19432.400018] EAX: ffe4 EBX: f60ac270 ECX: EDX: [19432.400018] ESI: f6612800 EDI: f0f40af4 EBP: f65b5eac ESP: f65b5e8c [19432.400018] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [19432.400018] Process cosd (pid: 1007, ti=f65b4000 task=f64c32c0 task.ti=f65b4000) [19432.400018] Stack: [19432.400018] 006c f0f409e0 f0f40af4 f60ac270 [19432.400018] 0 f65b5ebc c01eb4b0 f0f40af4 f65b5f38 f65b5ee4 f8568d36 f6d77000 [19432.400018] 0 f0f409e0 f6612800 f65b5f38 f0f40af4 f65b5ef8 f8568fc7 [19432.400018] Call Trace: [19432.400018] [c01eb4b0] ? vmtruncate+0x30/0x40 [19432.400018]
Re: btrfs write behavior on idle system
On 01/18/10 11:17, Carlos R. Mafra wrote: Hi everyone, I am using btrfs for my /home partition since I upgraded my slow laptop hdd for an ssd 3 weeks ago. I am always in sync with Linus' tree of the day (plus a btrfs patch which is not in there yet) and so far I haven't lost any data, so all is good. I have a question about the write behavior of the various [btrfs- ] kernel threads, as I've been monitoring what is writing to the ssd just in case. So what I've been observing with 'iostat', 'iotop' and 'blktrace' is the following. If my laptop is almost absolutely idle (just a plain Window Maker and a few xterms and a couple dockapps open) there is nothing writing to the disk (which is OK). But as soon as I leave an open tab in chrome (or firefox) the various [btrfs- ] threads start writing in my /home, and I don't know what. For testing purposes, I mounted the config dir of chrome (~/.config/google-chrome) in my SD card (at /dev/mmcblk0p1) to exclude the possibility of maybe chrome trying to update its history or something, so that it does not write anything in my /home partition with btrfs. But I see this in the output of 'iotop' from a 60 sec interval, showing only the processes which wrote something: Total DISK READ: 0 B/s | Total DISK WRITE: 10.26 K/s PID USER DISK READ DISK WRITE SWAPINIOCOMMAND 485 root 0 B/s5.19 K/s 0.00 % 0.02 % [btrfs-transacti] 3792 root 0 B/s 0 B/s 0.00 % 0.01 % [flush-btrfs-1] 476 root 0 B/s0.13 K/s 0.00 % 0.00 % [btrfs-delalloc-] 481 root 0 B/s4.93 K/s 0.00 % 0.00 % [btrfs-endio-wri] and there are more instances like this. Is there a way to avoid (or reduce) the writings of these threads? And when I start opening some pages in chrome and use it some more I get many many writes on my /home partition from these threads (and swapper, see below) even though I mounted the .config/google-chrome dir under /dev/mmcblk0p1 which uses ext4. From another experiment where chrome was showing a blank tab a ~7 minutes run of 'blktrace -a write /dev/sda3' (sda3 is my /home) ends like this (from 'blkparse -s sda3.blktrace.0'): - snip - Don't forget cache - should be under ~/.cache/google-chrome. That would probably explain the disk activity you're seeing. --Ravi Pinjala -- 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
Mounting multiple regular files as a filesystem
I'm trying to create a multi-device filesystem on top of regular files (not actual disks), and mount that to a loopback device. For a filesystem created on a single file, it works fine, but for a filesystem across multiple files, it doesn't. dd if=/dev/zero of=img1 bs=4096 count=65536 dd if=/dev/zero of=img2 bs=4096 count=65536 dd if=/dev/zero of=img3 bs=4096 count=65536 dd if=/dev/zero of=img4 bs=4096 count=65536 mkfs.btrfs img1 mount -o loop -t btrfs img1 /mnt/test # works mkfs.btrfs img1 img2 img3 img4 mount -o loop -t btrfs img1 /mnt/test # fails When I try to mount with multiple files, it also prints a message to syslog: Jun 15 00:32:10 3vil device fsid a147d6b950f66dca-3e2e7f52011c93b0 devid 4 transid 9 /dev/loop/0 Jun 15 00:32:10 3vil btrfs: failed to read chunk tree on loop0 Jun 15 00:32:10 3vil btrfs: open_ctree failed Am I doing something wrong, or is this use case broken right now? --Ravi -- 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
