Re: Corrupted filesystem, looking for guidance
Have same issue (RAID5 over 4 disks): https://marc.info/?l=linux-btrfs&m=154815802313248&w=2 Having perfectly healthy HDDs it seem to be caused by some bit flips in SDRAM which is non-ECC in my case, unfortunately. Tried --repair, didn't helped, same for --init-csum-tree. Now using fs in ro mode (data is fully available), preparing for total rebuild. -- Artem On Tue, Feb 12, 2019 at 5:17 AM Sébastien Luttringer wrote: > > Hello, > > The context is a BTRFS filesystem on top of an md device (raid5 on 6 disks). > System is an Arch Linux and the kernel was a vanilla 4.20.2. > > # btrfs fi us /home > Overall: > Device size: 27.29TiB > Device allocated: 5.01TiB > Device unallocated: 22.28TiB > Device missing: 0.00B > Used: 5.00TiB > Free (estimated): 22.28TiB (min: 22.28TiB) > Data ratio: 1.00 > Metadata ratio: 1.00 > Global reserve: 512.00MiB (used: 0.00B) > > Data,single: Size:4.95TiB, Used:4.95TiB >/dev/md127 4.95TiB > > Metadata,single: Size:61.01GiB, Used:57.72GiB >/dev/md127 61.01GiB > > System,single: Size:36.00MiB, Used:560.00KiB >/dev/md127 36.00MiB > > Unallocated: >/dev/md127 22.28TiB > > I'm not able to find the root cause of the btrfs corruption. All disks looks > healthy (selftest ok, no error logged), no kernel trace of link failure or > something. > I run a check on the md layer, and 2 mismatch was discovered: > Feb 11 04:02:35 kernel: md127: mismatch sector in range 490387096-490387104 > Feb 11 04:31:14 kernel: md127: mismatch sector in range 1024770720-1024770728 > I run a repair (resync) but mismatch are still around after. > > The first BTRFS warning was: > Feb 07 11:27:57 kernel: BTRFS warning (device md127): md127 checksum verify > failed on 4140883394560 wanted 7B4B0431 found B809FBEE level 0 > > > After that, the userland process crashed. Few days ago, I run it again. It > crashes again but filesystem become read-only > > Feb 10 01:07:02 kernel: BTRFS warning (device md127): md127 checksum verify > failed on 4140883394560 wanted 7B4B0431 found B809FBEE level 0 > Feb 10 01:07:03 kernel: BTRFS error (device md127): error loading props for > ino > 9930722 (root 5): -5 > Feb 10 01:07:03 kernel: BTRFS error (device md127): error loading props for > ino > 9930722 (root 5): -5 > Feb 10 01:07:03 kernel: BTRFS warning (device md127): md127 checksum verify > failed on 4140883394560 wanted 7B4B0431 found B809FBEE level 0 > Feb 10 01:07:03 kernel: BTRFS warning (device md127): md127 checksum verify > failed on 4140883394560 wanted 7B4B0431 found B809FBEE level 0 > Feb 10 01:07:03 kernel: BTRFS warning (device md127): md127 checksum verify > failed on 4140883394560 wanted 7B4B0431 found B809FBEE level 0 > Feb 10 01:07:03 kernel: BTRFS warning (device md127): md127 checksum verify > failed on 4140883394560 wanted 7B4B0431 found B809FBEE level 0 > Feb 10 01:07:03 kernel: BTRFS warning (device md127): md127 checksum verify > failed on 4140883394560 wanted 7B4B0431 found B809FBEE level 0 > Feb 10 01:07:03 kernel: BTRFS warning (device md127): md127 checksum verify > failed on 4140883394560 wanted 7B4B0431 found B809FBEE level 0 > Feb 10 01:07:03 kernel: BTRFS warning (device md127): md127 checksum verify > failed on 4140883394560 wanted 7B4B0431 found B809FBEE level 0 > Feb 10 01:07:03 kernel: BTRFS warning (device md127): md127 checksum verify > failed on 4140883394560 wanted 7B4B0431 found B809FBEE level 0 > Feb 10 03:16:24 kernel: BTRFS warning (device md127): md127 checksum verify > failed on 4140883394560 wanted 7B4B0431 found B809FBEE level 0 > Feb 10 03:16:28 kernel: BTRFS warning (device md127): md127 checksum verify > failed on 4140883394560 wanted 7B4B0431 found B809FBEE level 0 > Feb 10 03:27:34 kernel: BTRFS warning (device md127): md127 checksum verify > failed on 4140883394560 wanted 7B4B0431 found B809FBEE level 0 > Feb 10 03:27:40 kernel: BTRFS warning (device md127): md127 checksum verify > failed on 4140883394560 wanted 7B4B0431 found B809FBEE level 0 > Feb 10 05:59:34 kernel: BTRFS warning (device md127): md127 checksum verify > failed on 4140883394560 wanted 7B4B0431 found B809FBEE level 0 > Feb 10 05:59:34 kernel: BTRFS error (device md127): error loading props for > ino > 9930722 (root 5): -5 > Feb 10 05:59:34 kernel: BTRFS warning (device md127): md127 checksum verify > failed on 4140883394560 wanted 7B4B0431 found B809FBEE level 0 > Feb 10 05:59:34 kernel: BTRFS info (device md127): failed to delete reference > to fImage%252057(1).jpg, inode 9930722 parent 58718826 > Feb 1
btrfs RAID5 corrupted fs restore? data is OK
th 4096 [81685.702669] BTRFS critical (device sdf): unable to find logical 144149573654298624 length 4096 [81685.703231] BTRFS info (device sdf): no csum found for inode 13730923 start 1619410944 [81685.703235] BTRFS critical (device sdf): unable to find logical 144149573654298624 length 4096 [81685.703433] BTRFS critical (device sdf): unable to find logical 144149573654298624 length 4096 [81685.703606] BTRFS info (device sdf): no csum found for inode 13730923 start 1619410944 [81685.703608] BTRFS critical (device sdf): unable to find logical 144149573654298624 length 4096 [81685.703772] BTRFS critical (device sdf): unable to find logical 144149573654298624 length 4096 Any help is appreciated. Best regards, Artem Mygaiev
btrfs RAID5 corrupted fs restore? data is OK
Hello I am running Ubuntu Server 16.04 LTS with HWE stack (4.18 kernel). System is running on 2 protected SSDs in RAID1 mode, separate SSD assigned for swap and media download / processing cache and main data storage partition (read intense but not write intense, archive-like) is 32TB RAID5 btrfs (4x 8TB HDDs) mounted with following command: UUID=d2dfdbd4-a161-4ab9-85ef-3594e3a078b4 /mnt/Librarybtrfs defaults,degraded,noatime,nodiratime0 0 Recently I have started getting errors with my btrfs filesystem resulting it being mounted in ro mode. I have checked the data (I have checksums stored for all files, some are checked against cloud copies) and weirdly enough it was not corrupted. Of course, I cannot normally work with it while FS is in ro mode. I wonder can I do something with this without complete re-creating of btrfs filesystem. Note that disks seem to be physically fine - SMART reports no errors. Please see details below (I am sorry for the huge log, but I donno which part is useful) ~$ btrfs --version btrfs-progs v4.16.1 ~$ uname -a Linux kilimanjaro 4.18.0-13-generic #14~18.04.1-Ubuntu SMP Thu Dec 6 14:09:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux ~$ sudo btrfs filesystem show Label: none uuid: d2dfdbd4-a161-4ab9-85ef-3594e3a078b4 Total devices 4 FS bytes used 8.93TiB devid1 size 7.28TiB used 3.03TiB path /dev/sdf devid2 size 7.28TiB used 3.03TiB path /dev/sde devid3 size 7.28TiB used 3.03TiB path /dev/sdc devid4 size 7.28TiB used 3.03TiB path /dev/sdd ~$ btrfs fi df /mnt/Library/ Data, RAID5: total=9.08TiB, used=32.97GiB System, RAID5: total=96.00MiB, used=0.00B Metadata, RAID5: total=12.38GiB, used=6.53MiB GlobalReserve, single: total=512.00MiB, used=80.00KiB ~$ sudo dmesg [4.281851] BTRFS info (device sdf): allowing degraded mounts [4.281852] BTRFS info (device sdf): disk space caching is enabled [4.281853] BTRFS info (device sdf): has skinny extents [4.427649] BTRFS info (device sdf): bdev /dev/sdf errs: wr 0, rd 0, flush 0, corrupt 1, gen 0 [4.555937] BTRFS info (device sdf): checking UUID tree [ 35.829971] WARNING: CPU: 2 PID: 636 at /build/linux-hwe-jDoxDp/linux-hwe-4.18.0/fs/btrfs/locking.c:230 btrfs_tree_lock+0x203/0x220 [btrfs] [ 35.829974] Modules linked in: bonding nls_iso8859_1 snd_hda_codec_hdmi intel_rapl x86_pkg_temp_thermal intel_powerclamp eeepc_wmi kvm_intel ppdev asus_wmi wmi_bmof sparse_keymap mxm_wmi kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd cryptd glue_helper intel_cstate intel_rapl_perf snd_hda_codec_realtek input_leds snd_hda_codec_generic joydev snd_hda_intel snd_hda_codec snd_hda_core parport_pc snd_hwdep snd_pcm mei_me snd_timer mei snd soundcore mac_hid acpi_pad wmi ip6t_REJECT nf_reject_ipv6 xt_hl ip6t_rt nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4 xt_comment xt_multiport xt_limit xt_tcpudp xt_addrtype ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack ip6table_filter sch_fq_codel ip6_tables [ 35.830059] nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack nct6775 iptable_filter bpfilter hwmon_vid coretemp lp parport ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq libcrc32c hid_generic usbhid hid drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm ipmi_devintf r8169 ahci ipmi_msghandler mii libahci video [ 35.830113] CPU: 2 PID: 636 Comm: btrfs-cleaner Not tainted 4.18.0-13-generic #14~18.04.1-Ubuntu [ 35.830115] Hardware name: System manufacturer System Product Name/B150M-A, BIOS 3805 05/16/2018 [ 35.830163] RIP: 0010:btrfs_tree_lock+0x203/0x220 [btrfs] [ 35.830165] Code: 8b 04 25 00 5c 01 00 8b 80 a8 08 00 00 89 43 40 48 8b 45 e0 65 48 33 04 25 28 00 00 00 75 16 48 83 c4 30 5b 41 5c 41 5d 5d c3 <0f> 0b e9 32 fe ff ff 0f 0b eb c1 e8 4d 64 c2 e9 0f 1f 00 66 2e 0f [ 35.830244] RSP: 0018:abd6421e3ad0 EFLAGS: 00010246 [ 35.830249] RAX: 027c RBX: 93e2dfc14578 RCX: 000f83bd [ 35.830251] RDX: 93dec000 RSI: RDI: 93e2dfc14578 [ 35.830254] RBP: abd6421e3b18 R08: 93e2ddbbc6d8 R09: 93e2dfc14578 [ 35.830256] R10: 0040 R11: R12: 4000 [ 35.830259] R13: 93e2dff6b000 R14: 93e2e2a2 R15: 93e2dfc14578 [ 35.830263] FS: () GS:93e2fd90() knlGS: [ 35.830266] CS: 0010 DS: ES: CR0: 80050033 [ 35.830269] CR2: 7fe218b000c8 CR3: 00036bc0a004 CR4: 003606e0 [ 35.830271] Call Trace: [ 35.830312] btrfs_alloc_tree_block+0x17e/0x4b0 [btrfs] [ 35.830342] __btrfs_cow_block+0x119/0x550 [btrfs] [ 35.830372] btrfs_cow_block+0xdf/0x1a0 [btrfs] [ 35.830399] btrfs_search_slot+0x33b/0x9e0 [btrfs] [ 35.830409] ? kmem_cache_alloc+0x1a1/0x1d0 [ 35.830454] btrfs_update_dev
Re: imperfect FIEMAP results on btrfs
On Fri, 2013-05-03 at 09:31 +1000, Dave Chinner wrote: > IOWs, you simply can't assume that a specific test will give you the > same block layout across filesystems and different filesystem > configurations. Welcome to the world of "can't assume anything about > block layout" pain xfstests has been dealing with for years ;) This is what I also assumed, but wanted to get some feed-back from the community. Thanks a lot for the answer! -- Best Regards, Artem Bityutskiy -- 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
Re: imperfect FIEMAP results on btrfs
On Thu, 2013-05-02 at 19:00 +0300, Artem Bityutskiy wrote: > Notice 8 vs 16 blocks. Oh, the kernel is 3.8.6 -- Best Regards, Artem Bityutskiy -- 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
Re: [PATCH 07/16] btrfs: nuke write_super from comments
On Wed, 2012-07-25 at 09:46 -0600, cwillu wrote: > > mutex_lock(&root->fs_info->fs_devices->device_list_mutex); > > list_add_rcu(&device->dev_list, > > &root->fs_info->fs_devices->devices); > > list_add(&device->dev_alloc_list, > > Is the locking still required for approximately the same reason? I do not know, I assume Chris would check that. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
[PATCH 08/16] btrfs: nuke pdflush from comments
From: Artem Bityutskiy The pdflush thread is long gone, so this patch removes references to pdflush from btrfs comments. Cc: Chris Mason Cc: linux-btrfs@vger.kernel.org Signed-off-by: Artem Bityutskiy --- I expect this patch to be merged via Al Viro's VFS tree. fs/btrfs/inode.c|3 ++- fs/btrfs/ordered-data.c |2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index a7d1921..ca8b759 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -324,7 +324,8 @@ static noinline int add_async_extent(struct async_cow *cow, * If this code finds it can't get good compression, it puts an * entry onto the work queue to write the uncompressed bytes. This * makes sure that both compressed inodes and uncompressed inodes - * are written in the same order that pdflush sent them down. + * are written in the same order that the flusher thread sent them + * down. */ static noinline int compress_file_range(struct inode *inode, struct page *locked_page, diff --git a/fs/btrfs/ordered-data.c b/fs/btrfs/ordered-data.c index 643335a..051c7fe 100644 --- a/fs/btrfs/ordered-data.c +++ b/fs/btrfs/ordered-data.c @@ -596,7 +596,7 @@ void btrfs_start_ordered_extent(struct inode *inode, /* * pages in the range can be dirty, clean or writeback. We * start IO on any dirty ones so the wait doesn't stall waiting -* for pdflush to find them +* for the flusher thread to find them */ if (!test_bit(BTRFS_ORDERED_DIRECT, &entry->flags)) filemap_fdatawrite_range(inode->i_mapping, start, end); -- 1.7.10 -- 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
[PATCH 07/16] btrfs: nuke write_super from comments
From: Artem Bityutskiy
The '->write_super' superblock method is gone, and this patch removes all the
references to 'write_super' from btrfs.
Cc: Chris Mason
Cc: linux-btrfs@vger.kernel.org
Signed-off-by: Artem Bityutskiy
---
I expect this patch to be merged via Al Viro's VFS tree.
fs/btrfs/super.c |4
fs/btrfs/volumes.c |4
2 files changed, 8 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index e239915..ad31627 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -100,10 +100,6 @@ static void __save_error_info(struct btrfs_fs_info
*fs_info)
fs_info->fs_state = BTRFS_SUPER_FLAG_ERROR;
}
-/* NOTE:
- * We move write_super stuff at umount in order to avoid deadlock
- * for umount hold all lock.
- */
static void save_error_info(struct btrfs_fs_info *fs_info)
{
__save_error_info(fs_info);
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index ecaad40..9f2416c 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -1738,10 +1738,6 @@ int btrfs_init_new_device(struct btrfs_root *root, char
*device_path)
device->fs_devices = root->fs_info->fs_devices;
- /*
-* we don't want write_supers to jump in here with our device
-* half setup
-*/
mutex_lock(&root->fs_info->fs_devices->device_list_mutex);
list_add_rcu(&device->dev_list, &root->fs_info->fs_devices->devices);
list_add(&device->dev_alloc_list,
--
1.7.10
--
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
Re: File compression control, again.
Li Zefan cn.fujitsu.com> writes: > See this "Per file/directory controls for COW and compression": > > http://marc.info/?l=linux-btrfs&m=130078867208491&w=2 Thanks again! I wrote a program to see if ioctl compression control works ( https://gist.github.com/1248085 ) and it does! : ) -- 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
Re: File compression control, again.
Li Zefan cn.fujitsu.com> writes: > See this "Per file/directory controls for COW and compression": > > http://marc.info/?l=linux-btrfs&m=130078867208491&w=2 > > And the user tool patch (which got no reply): > > http://marc.info/?l=linux-btrfs&m=130311215721242&w=2 > > So you can create a directory, and set the no-compress flag for it, and > then any file created in that dir will inherit the flag. Thanks, Li, but how do I set the no-compress flag? The patched chattr you mention can only set the FS_COMPR_FL. The 'C' argument is now used for FS_NOCOW_FL. Could we use another flag for copy-on-write control in chattr? -- 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
File compression control, again.
Hi! So, it makes sense to keep the compression on by default and with LZO many people are going there. But, I want to create a database on a compressed btrfs filesystem which is seek-heavy rather than throughput-heavy and I really want to turn the compression off just for that database (smaller I/O reads, more precise cache usage). Maintenance nightmare that Miguel mentioned ( http://thread.gmane.org/gmane.comp.file-systems.btrfs/1665/focus=1669 ) isn't really a problem as I'm going to automatically set the flags from the program, just before opening the database. Looking at "fs/btrfs/ioctl.h" I don't see any way to to this. Subvolume compression control isn't working either from what I heard (cf. https://bbs.archlinux.org/viewtopic.php?id=126635 http://thread.gmane.org/gmane.comp.file-systems.btrfs/6237/ ). Am I right that fine-grained compression control is no longer supported by btrfs? If so, I would like to vote for it to be added. -- 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
Re: Dirtiable inode bdi default != sb bdi btrfs
On Wed, 2010-09-29 at 15:00 +0200, Jan Kara wrote: > On Tue 28-09-10 10:05:49, Artem Bityutskiy wrote: > > On Mon, 2010-09-27 at 18:54 -0400, Chris Mason wrote: > > > On Tue, Sep 28, 2010 at 12:25:48AM +0200, Jan Kara wrote: > > > > [Added CCs for similar ecryptfs warning] > > > > On Thu 23-09-10 12:38:49, Andrew Morton wrote: > > > > > > This started appearing for me on v2.6.36-rc5-49-gc79bd89; it did > > > > > > not > > > > > > happen on v2.6.36-rc5-33-g1ce1e41, probably because it does not > > > > > > have > > > > > > commit 692ebd17c2905313fff3c504c249c6a0faad16ec which introduces > > > > > > the > > > > > > warning. > > > > > > [...] > > > > > > device fsid 44d595920ddedfa-3ece6b56e80f689e devid 1 transid 22342 > > > > > > /dev/mapper/vg_cesarbinspiro-lv_home > > > > > > SELinux: initialized (dev dm-3, type btrfs), uses xattr > > > > > > [ cut here ] > > > > > > WARNING: at fs/fs-writeback.c:87 inode_to_bdi+0x62/0x6d() > > > > > > Hardware name: Inspiron N4010 > > > > > > Dirtiable inode bdi default != sb bdi btrfs > > > > > > Modules linked in: ipv6 kvm_intel kvm uinput arc4 ecb > > > > > > snd_hda_codec_intelhdmi snd_hda_codec_realtek iwlagn snd_hda_intel > > > > > > iwlcore snd_hda_codec uvcvideo snd_hwdep mac80211 videodev snd_seq > > > > > > snd_seq_device v4l1_compat snd_pcm atl1c v4l2_compat_ioctl32 btusb > > > > > > cfg80211 snd_timer i2c_i801 bluetooth iTCO_wdt dell_wmi dell_laptop > > > > > > snd > > > > > > pcspkr wmi dcdbas shpchp iTCO_vendor_support soundcore > > > > > > snd_page_alloc > > > > > > rfkill joydev microcode btrfs zlib_deflate libcrc32c cryptd > > > > > > aes_x86_64 > > > > > > aes_generic xts gf128mul dm_crypt usb_storage i915 drm_kms_helper > > > > > > drm > > > > > > i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan] > > > > > > Pid: 1073, comm: find Not tainted 2.6.36-rc5+ #8 > > > > > > Call Trace: > > > > > > [] warn_slowpath_common+0x85/0x9d > > > > > > [] warn_slowpath_fmt+0x46/0x48 > > > > > > [] inode_to_bdi+0x62/0x6d > > > > > > [] __mark_inode_dirty+0xd0/0x177 > > > > > > [] touch_atime+0x107/0x12a > > > > > > [] ? filldir+0x0/0xd0 > > > > > > [] vfs_readdir+0x8d/0xb4 > > > > > > [] sys_getdents+0x81/0xd1 > > > > > > [] system_call_fastpath+0x16/0x1b > > > > Thanks for the report. These bdi pointers are a mess. As Chris pointed > > > > out, btrfs forgets to properly initialize > > > > inode->i_mapping.backing_dev_info > > > > for directories and special inodes and thus these were previously > > > > attached > > > > to default_backing_dev_info which probably isn't what Chris would like > > > > to > > > > see. > > > > > > There's no actual writeback for these, so it works fine for btrfs either > > > way. > > > > Side note: every time inode is marked as dirty, we wake up a bdi thread > > or the default bdi thread. So if we have inodes which do not need > > write-back, we should never mark them as dirty. > Are you sure? I think we wake up the thread only when it's the first > dirty inode for the bdi... Err, right. If no one ever marks it as clean then we won't wake-up the thread. But I thought that marking it as dirty even once is bad because this causes bdi thread creation, which consumes resources. Sorry for my ignorance, I did not really follow the conversation, I just remember that when I looked at bdi stuff, I noticed that during boot the kernel created many bdi threads which were never used then. They eventually exited. But I thought that creating useless bdi threads it about concuming resources and slowing down the boot. As I remember, the reason was touch_atime() for some of the threads. But really, I did not dig this, I just noticed this conversation and wanted to let you know about the issue I noticed this summer. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- 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
Re: Dirtiable inode bdi default != sb bdi btrfs
On Mon, 2010-09-27 at 18:54 -0400, Chris Mason wrote: > On Tue, Sep 28, 2010 at 12:25:48AM +0200, Jan Kara wrote: > > [Added CCs for similar ecryptfs warning] > > On Thu 23-09-10 12:38:49, Andrew Morton wrote: > > > > This started appearing for me on v2.6.36-rc5-49-gc79bd89; it did not > > > > happen on v2.6.36-rc5-33-g1ce1e41, probably because it does not have > > > > commit 692ebd17c2905313fff3c504c249c6a0faad16ec which introduces the > > > > warning. > > > > [...] > > > > device fsid 44d595920ddedfa-3ece6b56e80f689e devid 1 transid 22342 > > > > /dev/mapper/vg_cesarbinspiro-lv_home > > > > SELinux: initialized (dev dm-3, type btrfs), uses xattr > > > > [ cut here ] > > > > WARNING: at fs/fs-writeback.c:87 inode_to_bdi+0x62/0x6d() > > > > Hardware name: Inspiron N4010 > > > > Dirtiable inode bdi default != sb bdi btrfs > > > > Modules linked in: ipv6 kvm_intel kvm uinput arc4 ecb > > > > snd_hda_codec_intelhdmi snd_hda_codec_realtek iwlagn snd_hda_intel > > > > iwlcore snd_hda_codec uvcvideo snd_hwdep mac80211 videodev snd_seq > > > > snd_seq_device v4l1_compat snd_pcm atl1c v4l2_compat_ioctl32 btusb > > > > cfg80211 snd_timer i2c_i801 bluetooth iTCO_wdt dell_wmi dell_laptop snd > > > > pcspkr wmi dcdbas shpchp iTCO_vendor_support soundcore snd_page_alloc > > > > rfkill joydev microcode btrfs zlib_deflate libcrc32c cryptd aes_x86_64 > > > > aes_generic xts gf128mul dm_crypt usb_storage i915 drm_kms_helper drm > > > > i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan] > > > > Pid: 1073, comm: find Not tainted 2.6.36-rc5+ #8 > > > > Call Trace: > > > > [] warn_slowpath_common+0x85/0x9d > > > > [] warn_slowpath_fmt+0x46/0x48 > > > > [] inode_to_bdi+0x62/0x6d > > > > [] __mark_inode_dirty+0xd0/0x177 > > > > [] touch_atime+0x107/0x12a > > > > [] ? filldir+0x0/0xd0 > > > > [] vfs_readdir+0x8d/0xb4 > > > > [] sys_getdents+0x81/0xd1 > > > > [] system_call_fastpath+0x16/0x1b > > Thanks for the report. These bdi pointers are a mess. As Chris pointed > > out, btrfs forgets to properly initialize inode->i_mapping.backing_dev_info > > for directories and special inodes and thus these were previously attached > > to default_backing_dev_info which probably isn't what Chris would like to > > see. > > There's no actual writeback for these, so it works fine for btrfs either > way. Side note: every time inode is marked as dirty, we wake up a bdi thread or the default bdi thread. So if we have inodes which do not need write-back, we should never mark them as dirty. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- 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
