From: Artem Bityutskiy <dedekind1@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: "Chris Mason" <chris.mason@oracle.com>,
"Cesar Eduardo Barros" <cesarb@cesarb.net>,
"Andrew Morton" <akpm@linux-foundation.org>,
hch@lst.de, linux-kernel@vger.kernel.org,
"Jens Axboe" <jaxboe@fusionio.com>,
linux-btrfs@vger.kernel.org,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, stable@kernel.org,
"Jens Axboe" <axboe@kernel.dk>,
"Michał Piotrowski" <mkkp4x4@gmail.com>,
"Chuck Ebbert" <cebbert@redhat.com>,
kernel@lists.fedoraproject.org
Subject: Re: Dirtiable inode bdi default != sb bdi btrfs
Date: Wed, 29 Sep 2010 16:40:16 +0300 [thread overview]
Message-ID: <1285767616.2437.142.camel@localhost> (raw)
In-Reply-To: <20100929130056.GG3290@quack.suse.cz>
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; i=
t did not=20
> > > > > > happen on v2.6.36-rc5-33-g1ce1e41, probably because it does=
not have=20
> > > > > > commit 692ebd17c2905313fff3c504c249c6a0faad16ec which intro=
duces the=20
> > > > > > warning.
> > > > > > [...]
> > > > > > device fsid 44d595920ddedfa-3ece6b56e80f689e devid 1 transi=
d 22342=20
> > > > > > /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 !=3D sb bdi btrfs
> > > > > > Modules linked in: ipv6 kvm_intel kvm uinput arc4 ecb=20
> > > > > > snd_hda_codec_intelhdmi snd_hda_codec_realtek iwlagn snd_hd=
a_intel=20
> > > > > > iwlcore snd_hda_codec uvcvideo snd_hwdep mac80211 videodev =
snd_seq=20
> > > > > > snd_seq_device v4l1_compat snd_pcm atl1c v4l2_compat_ioctl3=
2 btusb=20
> > > > > > cfg80211 snd_timer i2c_i801 bluetooth iTCO_wdt dell_wmi del=
l_laptop snd=20
> > > > > > pcspkr wmi dcdbas shpchp iTCO_vendor_support soundcore snd_=
page_alloc=20
> > > > > > rfkill joydev microcode btrfs zlib_deflate libcrc32c cryptd=
aes_x86_64=20
> > > > > > aes_generic xts gf128mul dm_crypt usb_storage i915 drm_kms_=
helper drm=20
> > > > > > i2c_algo_bit i2c_core video output [last unloaded: scsi_wai=
t_scan]
> > > > > > Pid: 1073, comm: find Not tainted 2.6.36-rc5+ #8
> > > > > > Call Trace:
> > > > > > [<ffffffff8104d0e4>] warn_slowpath_common+0x85/0x9d
> > > > > > [<ffffffff8104d19f>] warn_slowpath_fmt+0x46/0x48
> > > > > > [<ffffffff811308b7>] inode_to_bdi+0x62/0x6d
> > > > > > [<ffffffff81131b48>] __mark_inode_dirty+0xd0/0x177
> > > > > > [<ffffffff81127168>] touch_atime+0x107/0x12a
> > > > > > [<ffffffff81122384>] ? filldir+0x0/0xd0
> > > > > > [<ffffffff8112259b>] vfs_readdir+0x8d/0xb4
> > > > > > [<ffffffff8112270b>] sys_getdents+0x81/0xd1
> > > > > > [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b
> > > > Thanks for the report. These bdi pointers are a mess. As Chri=
s pointed
> > > > out, btrfs forgets to properly initialize inode->i_mapping.back=
ing_dev_info
> > > > for directories and special inodes and thus these were previous=
ly attached
> > > > to default_backing_dev_info which probably isn't what Chris wou=
ld like to
> > > > see.
> > >=20
> > > There's no actual writeback for these, so it works fine for btrfs=
either
> > > way.
> >=20
> > Side note: every time inode is marked as dirty, we wake up a bdi th=
read
> > 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 firs=
t
> 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 jus=
t
remember that when I looked at bdi stuff, I noticed that during boot th=
e
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.
--=20
Best Regards,
Artem Bityutskiy (=D0=90=D1=80=D1=82=D1=91=D0=BC =D0=91=D0=B8=D1=82=D1=8E=
=D1=86=D0=BA=D0=B8=D0=B9)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: "Chris Mason" <chris.mason@oracle.com>,
"Cesar Eduardo Barros" <cesarb@cesarb.net>,
"Andrew Morton" <akpm@linux-foundation.org>,
hch@lst.de, linux-kernel@vger.kernel.org,
"Jens Axboe" <jaxboe@fusionio.com>,
linux-btrfs@vger.kernel.org,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, stable@kernel.org,
"Jens Axboe" <axboe@kernel.dk>,
"Michał Piotrowski" <mkkp4x4@gmail.com>,
"Chuck Ebbert" <cebbert@redhat.com>,
kernel@lists.fedoraproject.org
Subject: Re: Dirtiable inode bdi default != sb bdi btrfs
Date: Wed, 29 Sep 2010 16:40:16 +0300 [thread overview]
Message-ID: <1285767616.2437.142.camel@localhost> (raw)
In-Reply-To: <20100929130056.GG3290@quack.suse.cz>
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:
> > > > > > [<ffffffff8104d0e4>] warn_slowpath_common+0x85/0x9d
> > > > > > [<ffffffff8104d19f>] warn_slowpath_fmt+0x46/0x48
> > > > > > [<ffffffff811308b7>] inode_to_bdi+0x62/0x6d
> > > > > > [<ffffffff81131b48>] __mark_inode_dirty+0xd0/0x177
> > > > > > [<ffffffff81127168>] touch_atime+0x107/0x12a
> > > > > > [<ffffffff81122384>] ? filldir+0x0/0xd0
> > > > > > [<ffffffff8112259b>] vfs_readdir+0x8d/0xb4
> > > > > > [<ffffffff8112270b>] sys_getdents+0x81/0xd1
> > > > > > [<ffffffff81009c72>] 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 (Артём Битюцкий)
WARNING: multiple messages have this Message-ID (diff)
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: "Chris Mason" <chris.mason@oracle.com>,
"Cesar Eduardo Barros" <cesarb@cesarb.net>,
"Andrew Morton" <akpm@linux-foundation.org>,
hch@lst.de, linux-kernel@vger.kernel.org,
"Jens Axboe" <jaxboe@fusionio.com>,
linux-btrfs@vger.kernel.org,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, stable@kernel.org,
"Jens Axboe" <axboe@kernel.dk>,
"Michał Piotrowski" <mkkp4x4@gmail.com>,
"Chuck Ebbert" <cebbert@redhat.com>,
kernel@lists.fedoraproject.org
Subject: Re: Dirtiable inode bdi default != sb bdi btrfs
Date: Wed, 29 Sep 2010 16:40:16 +0300 [thread overview]
Message-ID: <1285767616.2437.142.camel@localhost> (raw)
In-Reply-To: <20100929130056.GG3290@quack.suse.cz>
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:
> > > > > > [<ffffffff8104d0e4>] warn_slowpath_common+0x85/0x9d
> > > > > > [<ffffffff8104d19f>] warn_slowpath_fmt+0x46/0x48
> > > > > > [<ffffffff811308b7>] inode_to_bdi+0x62/0x6d
> > > > > > [<ffffffff81131b48>] __mark_inode_dirty+0xd0/0x177
> > > > > > [<ffffffff81127168>] touch_atime+0x107/0x12a
> > > > > > [<ffffffff81122384>] ? filldir+0x0/0xd0
> > > > > > [<ffffffff8112259b>] vfs_readdir+0x8d/0xb4
> > > > > > [<ffffffff8112270b>] sys_getdents+0x81/0xd1
> > > > > > [<ffffffff81009c72>] 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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-09-29 13:40 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-23 0:54 Dirtiable inode bdi default != sb bdi btrfs Cesar Eduardo Barros
2010-09-23 19:38 ` Andrew Morton
2010-09-23 19:40 ` Chris Mason
2010-09-23 19:40 ` Jens Axboe
2010-09-23 20:53 ` [stable] " Greg KH
2010-09-24 18:39 ` Jens Axboe
2010-09-27 0:15 ` Greg KH
2010-09-27 22:25 ` Jan Kara
2010-09-27 22:54 ` Chris Mason
2010-09-27 23:51 ` Jan Kara
2010-09-27 23:51 ` Jan Kara
2010-09-28 7:05 ` Artem Bityutskiy
2010-09-28 7:05 ` Artem Bityutskiy
2010-09-29 13:00 ` Jan Kara
2010-09-29 13:40 ` Artem Bityutskiy [this message]
2010-09-29 13:40 ` Artem Bityutskiy
2010-09-29 13:40 ` Artem Bityutskiy
2010-09-29 8:19 ` Christoph Hellwig
2010-09-29 8:19 ` Christoph Hellwig
2010-09-29 8:19 ` Christoph Hellwig
2010-09-29 12:18 ` Jan Kara
2010-09-29 12:18 ` Jan Kara
2010-09-29 14:10 ` Christoph Hellwig
2010-09-29 23:38 ` Jan Kara
2010-09-29 23:38 ` Jan Kara
2010-09-30 0:06 ` Christoph Hellwig
2010-09-30 0:06 ` Christoph Hellwig
2010-09-27 23:55 ` Cesar Eduardo Barros
2010-09-29 13:01 ` Jan Kara
2010-09-29 13:01 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1285767616.2437.142.camel@localhost \
--to=dedekind1@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=cebbert@redhat.com \
--cc=cesarb@cesarb.net \
--cc=chris.mason@oracle.com \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=jaxboe@fusionio.com \
--cc=kernel@lists.fedoraproject.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mkkp4x4@gmail.com \
--cc=stable@kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.