Re: Dirtiable inode bdi default != sb bdi btrfs
[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.
I've also got a similar report for ecryptfs which also does not
initialize inode->i_mapping.backing_dev_info although it sets sb->s_bdi and
thus again its inodes get filed to default_backing_dev_info lists. Quick
search seems to reveal that other filesystems using handcrafted bdi's get
it wrong as well and thus their inodes end up in the default_backing_dev_info
lists which is generally undesirable (this was happening already before my
patch, my code just started complaining about that).
That suggests that we should probably handle such cases in a more generic
way by changing the code in inode_init_always(). The patch below makes at
least btrfs happy for me... Could you maybe test it? Thanks.
Honza
--
Jan Kara
SUSE Labs, CR
---
>From 29f60c2b08ff9637a10439d1513805835ddcc746 Mon Sep 17 00:00:00 2001
From: Jan Kara
Date: Mon, 27 Sep 2010 23:56:48 +0200
Subject: [PATCH] bdi: Initialize inode->i_mapping.backing_dev_info to sb->s_bdi
Currently, we initialize inode->i_mapping.backing_dev_info to the bdi of device
sb->s_bdev points to. However there is quite a big number of filesystems that
do not set sb->s_bdev (because they do not have one) but do set sb->s_bdi.
These filesystems would generally benefit from setting
inode->i_mapping.backing_dev_info to their s_bdi because otherwise their inodes
would point to default_backing_dev_info and thus dirty inode tracking would
happen there. So change inode initialization code to use sb->s_bdi if it
is available.
Signed-off-by: Jan Kara
---
fs/inode.c | 22 ++
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/fs/inode.c b/fs/inode.c
index 8646433..e415be4 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -172,15 +172,21 @@ int inode_init_always(struct super_block *sb, struct
inode *inode)
mapping->writeback_index = 0;
/*
-* If the block_device provides a backing_dev_info for client
-* inodes then use that. Otherwise the inode share the bdev's
-* backing_dev_info.
+* If the filesystem provides a backing_dev_info for client inodes
+* then use that. Otherwise inodes share default_backing_dev_info.
*/
- if (sb->s_bdev) {
- struct backing_dev_info *bdi;
-
- bdi = sb->s_bdev->bd_inode->i_mapping->backing_dev_info;
- mapping->backing_dev_info = bdi;
+ if (sb->s_bdi && sb->s_bdi != &noop_backing_dev_info) {
+ /*
+* Catch cases where filesystem might be bitten by using s_bdi
+* instead of sb->s_bdev. Can be removed in 2.6.38.
+*/
+ if (sb->s_bdev) {
+ struct backing_dev_info *bdi =
+ sb->s_bdev->bd_inode->i_mapping->backing_dev_info;
+ WARN(bdi != sb->s_bdi, "s_bdev bdi %s != s_bdi %s\n",
+bdi->name
btrfs user survey?
Hello list, At this point in time, btrfs has gained a lot of interest, and not only a passing one. So, it is, imho, the ideal time to build up a survey to monitor how btrfs is used today (or _was_ used - I have knowledge of people that started to use it but dropped for various reasons). Of course, I'm only one user among many, but here is a sample of questions for this survey in case anyone is interested: * Do you use btrfs currently? [ ] yes, but not as a root filesystem [ ] yes, as a root filesystem [ ] no * If not, what prevents you from using them? [ ] lack of a full blown fsck [ ] horror stories from other users [ ] lack of support from my favorite distribution [ ] other * If yes, how long have you used it? [ put answers here related to milestones in btrfs design - I don't know them ] * Do you use the following features of btrfs: [ ] defragment [ ] online shrink [ ] online expand [ ] snapshots [ ] RAID [ ] [others - I only mention the ones I know] * How many btrfs filesystems do you currently have? [ ] 1 only [ ] 2-5 [ ] More than 5 * How many btrfs filesystems have failed upon you? [ ] None! [ ] [etc etc] Well, all in all, you get the idea, and I'm probably not the guy to craft questions for such a survey. But having input from as large a panel of users as possible would be a nice thing to have. Comments? -- Francis Galiegue, fgalie...@gmail.com "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (Stéphane Faroult, in "The Art of SQL", ISBN 0-596-00894-5) -- 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: btrfs user survey?
Hi Francis, > Well, all in all, you get the idea, and I'm probably not the guy > to craft questions for such a survey. But having input from as > large a panel of users as possible would be a nice thing to have. Your questions are fine -- I might add: * Rank the following future features in importance, 4 == most important [ ] working fsck [ ] GUIs for userspace actions e.g. snapshots [ ] data deduplication [ ] hot data relocation Please use something like Google Spreadsheets (which has a forms option) if you're going to run such a survey, rather than having everyone reply on-list -- we shouldn't bother this list with any results other than the final summary. - Chris. -- Chris Ball One Laptop Per Child -- 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 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.
> I've also got a similar report for ecryptfs which also does not
> initialize inode->i_mapping.backing_dev_info although it sets sb->s_bdi and
> thus again its inodes get filed to default_backing_dev_info lists. Quick
> search seems to reveal that other filesystems using handcrafted bdi's get
> it wrong as well and thus their inodes end up in the default_backing_dev_info
> lists which is generally undesirable (this was happening already before my
> patch, my code just started complaining about that).
> That suggests that we should probably handle such cases in a more generic
> way by changing the code in inode_init_always(). The patch below makes at
> least btrfs happy for me... Could you maybe test it? Thanks.
Christoph had a slightly different plan for this, I've cc'd him and kept
the patch below for comment.
-chris
>
> Honza
> --
> Jan Kara
> SUSE Labs, CR
> ---
>
> From 29f60c2b08ff9637a10439d1513805835ddcc746 Mon Sep 17 00:00:00 2001
> From: Jan Kara
> Date: Mon, 27 Sep 2010 23:56:48 +0200
> Subject: [PATCH] bdi: Initialize inode->i_mapping.backing_dev_info to
> sb->s_bdi
>
> Currently, we initialize inode->i_mapping.backing_dev_info to the bdi of
> device
> sb->s_bdev points to. However there is quite a big number of filesystems that
> do not set sb->s_bdev (because they do not have one) but do set sb->s_bdi.
> These filesystems would generally benefit from setting
> inode->i_mapping.backing_dev_info to their s_bdi because otherwise their
> inodes
> would point to default_backing_dev_info and thus dirty inode tracking would
> happen there. So change inode initialization code to use sb->s_bdi if it
> is available.
>
> Signed-off-by: Jan Kara
> ---
> fs/inode.c | 22 ++
> 1 files changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/fs/inode.c b/fs/inode.c
> index 8646433..e415be4 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -172,15 +172,21 @@ int inode_init_always(struct super_block *sb, struct
> inode *inode)
> mapping->writeback_index = 0;
>
> /*
> - * If the block_device provides a backing_dev_info for client
> - * inodes then use that. Otherwise the inode share the bdev's
> - * backing_dev_info.
> + * If the filesystem provides a backing_dev_info for client inodes
> + * then use that. Otherwise inodes share default_backing_dev_info.
>*/
> - if (sb->s_bdev) {
> - struct backing_dev_info *bdi;
> -
> - bdi = sb->s_bdev->bd_inode->i_mapping->backing_dev_info;
> - mapping->backing_dev_info = bdi;
> + if (sb->s_bdi && sb->s_bdi != &noop_backing_dev_info) {
> + /*
> + * Catch ca
Re: btrfs user survey?
On Mon, Sep 27, 2010 at 3:44 PM, Chris Ball wrote: > > Well, all in all, you get the idea, and I'm probably not the guy > > to craft questions for such a survey. But having input from as > > large a panel of users as possible would be a nice thing to have. > > Your questions are fine -- I might add: > > * Rank the following future features in importance, 4 == most important > [ ] working fsck > [ ] GUIs for userspace actions e.g. snapshots > [ ] data deduplication > [ ] hot data relocation You're missing RAID levels above 1, and deduplication. :) (And probably a few others.) > Please use something like Google Spreadsheets (which has a forms > option) if you're going to run such a survey, rather than having > everyone reply on-list -- we shouldn't bother this list with any > results other than the final summary. Something like SurveyMonkey (http://www.surveymonkey.com) or SurveyGizmo (http://www.surveygizmo.com) or similar would be better, as it does all the reporting for you, builds the nice survey interface with checkboxes, radio buttons, text fields, etc. And they're still free (as in beer). -- Freddie Cash fjwc...@gmail.com -- 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: kernel BUG at fs/btrfs/volumes.c:3017!
On Sun, 2010-09-26 at 13:25 +0300, Markus Suvanto wrote: > This time kernel is 2.6.36-rc5-00151-g32163f4 > no reverted commits no openafs module and > hopefully enough debug information > > There are multiple warning: > > ---[ end trace a72eccec168b ]--- > [ cut here ] > WARNING: at fs/fs-writeback.c:87 __mark_inode_dirty+0x1da/0x220() I'm also seeing this warning, or something very much like it, as below: [7.382345] [ cut here ] [7.382351] WARNING: at fs/fs-writeback.c:87 inode_to_bdi+0x5d/0x68() [7.382353] Hardware name: EX58-DS4 [7.382354] Dirtiable inode bdi default != sb bdi btrfs [7.382355] Modules linked in: ir_lirc_codec lirc_dev ir_sony_decoder radeon ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder usblp ir_nec_decoder ttm mceusb ir_core drm_kms_helper cfbcopyarea cfbimgblt cfbfillrect [7.382366] Pid: 1245, comm: dbus-daemon Not tainted 2.6.36-rc5-00151-g32163f4 #88 [7.382368] Call Trace: [7.382371] [] warn_slowpath_common+0x80/0x98 [7.382374] [] warn_slowpath_fmt+0x41/0x43 [7.382376] [] inode_to_bdi+0x5d/0x68 [7.382379] [] __mark_inode_dirty+0xcf/0x1a2 [7.382382] [] btrfs_setattr+0x1fc/0x22d [7.382385] [] notify_change+0x1a1/0x2a1 [7.382389] [] sys_fchmodat+0x81/0xc0 [7.382391] [] ? fput+0x1d/0x1a4 [7.382393] [] ? sys_fcntl+0x4ca/0x4dc [7.382395] [] sys_chmod+0x13/0x15 [7.382399] [] system_call_fastpath+0x16/0x1b [7.382400] ---[ end trace beeec739c7ec991e ]--- This happens repeatedly every couple of minutes after my computer has booted. It looks like this is pretty recent; I don't recall seeing it on 2.6.36-rc4-00076-g9c03f16. If nobody has any ideas regarding the cause, I can try bisecting it to narrow it down; let me know! -- Calvin Walton -- 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 27-09-10 18:54:52, 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. Ah, OK. I see you do all the writing already at inode dirtying time so you don't really care what happens after the dirtying for inodes without page cache. So it's really just a cosmetic issue for btrfs. > > I've also got a similar report for ecryptfs which also does not > > initialize inode->i_mapping.backing_dev_info although it sets sb->s_bdi and > > thus again its inodes get filed to default_backing_dev_info lists. Quick > > search seems to reveal that other filesystems using handcrafted bdi's get > > it wrong as well and thus their inodes end up in the > > default_backing_dev_info > > lists which is generally undesirable (this was happening already before my > > patch, my code just started complaining about that). > > That suggests that we should probably handle such cases in a more generic > > way by changing the code in inode_init_always(). The patch below makes at > > least btrfs happy for me... Could you maybe test it? Thanks. > > Christoph had a slightly different plan for this, I've cc'd him and kept > the patch below for comment. OK, thanks. Honza > > --- > > > > From 29f60c2b08ff9637a10439d1513805835ddcc746 Mon Sep 17 00:00:00 2001 > > From: Jan Kara > > Date: Mon, 27 Sep 2010 23:56:48 +0200 > > Subject: [PATCH] bdi: Initialize inode->i_mapping.backing_dev_info to > > sb->s_bdi > > > > Currently, we initialize inode->i_mapping.backing_dev_info to the bdi of > > device > > sb->s_bdev points to. However there is quite a big number of filesystems > > that > > do not set sb->s_bdev (because they do not have one) but do set sb->s_bdi. > > These filesystems would generally benefit from setting > > inode->i_mapping.backing_dev_info to their s_bdi because otherwise their > > inodes > > would point to default_backing_dev_info and thus dirty inode tracking would > > happen there. So change inode initialization code to use sb->s_bdi if it > > is available. > > > > Signed-off-by: Jan Kara > > --- > > fs/inode.c | 22 ++ > > 1 files changed, 14 insertions(+), 8 deletions(-) > > > > diff --git a/fs/inode.c b/fs/inode.c > > index 8646433..e415be4 100644 > > --- a/fs/inode.c > > +++ b/fs/inode.c > > @@ -172,15 +172,21 @@ int inode_init_always(struct super_block *sb, struct > > inode *inode) > > mapping->writeback_index = 0; > > > > /* > > -* If the block_device provides a backing_dev_info for client > > -* inodes then use that. Otherwise the inode share the bdev's > > -* backing_dev_info. > > +* If the filesystem provides a backing_dev_info for clien
Re: Dirtiable inode bdi default != sb bdi btrfs
Em 27-09-2010 19:25, Jan Kara escreveu: [Added CCs for similar ecryptfs warning] On Thu 23-09-10 12:38:49, Andrew Morton wrote: [...] 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 That suggests that we should probably handle such cases in a more generic way by changing the code in inode_init_always(). The patch below makes at least btrfs happy for me... Could you maybe test it? Thanks. Applied on top of v2.6.36-rc5-151-g32163f4, running it right now. The warning messages no longer happen, and everything seems to be working fine. Tested-by: Cesar Eduardo Barros -- Cesar Eduardo Barros ces...@cesarb.net cesar.bar...@gmail.com -- 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
