All of lore.kernel.org
 help / color / mirror / Atom feed
* speeding up slow btrfs filesystem
@ 2011-12-16 17:51 Martin Steigerwald
  2011-12-16 17:54 ` Martin Steigerwald
  2011-12-17 11:11 ` Chris Samuel
  0 siblings, 2 replies; 24+ messages in thread
From: Martin Steigerwald @ 2011-12-16 17:51 UTC (permalink / raw)
  To: linux-btrfs

Hi!

On apt-get dist-upgrading my Amarok ThinkPad T23 with BTRFS as /
and as /home I get extremely slow operation - my ThinkPad T42 with Ext4
is running circles around it and thats likely not only due to the faste=
r CPU.

vmstat 1 shows:

procs -----------memory---------- ---swap-- -----io---- -system-- ----c=
pu----
 0  4 151452  75016     68 382084    0    0  1164    28  595 1959 31 19=
  0 50
 0  3 151452  74272     68 382560    0    0   488     0  538 1735 10  9=
  0 81
 4  2 151452  71644     68 385776    0    0  3804     0  663 1886 56 38=
  0  6
 3  2 151452  66916     68 387192    0    0  1264     0  633 1018 74 24=
  0  2
 1  3 151452  63296     68 389336    0    0  1580     0  656 4095 80 20=
  0  0
 2  3 151452  66272     68 390028    8    0   572     0  601 3449 40 17=
  0 43
 3  2 151452  65032     68 390828    0    0   760     0  673 2364 42 25=
  0 32
 3  2 151452  61816     68 393508    0    0  2672     0  748 2203 52 29=
  0 19
 2  2 151452  60824     68 394236    0    0   724     0  660 2338 51 22=
  0 27
 4  2 151452  59832     68 395024    0    0   808     0  662 2309 40 20=
  0 40
 0  2 151452  58708     68 395856    0    0   812    12  683 2217 46 23=
  0 30
 0  2 151452  57964     68 396416    0    0   512     0  619 2196 41 24=
  0 35

I know laptop harddisks aren=B4t the fastest, but AFAIR the T23 felt wa=
y faster
with Ext3/4.

I get quite some stalles when opening a new window in "screen". It can =
take
10-20 seconds to load the new Z-Shell into it. Also Amarok stops playin=
g
music for a while sometimes which it didn=B4t with Ext3/4. I suspect th=
at the
kernel does not service an I/O request of Amarok quickly enough.

Surprisingly I do not see an excessive amount of CPU usage of brtfs ker=
nel
threads with atop. But the disk seems to be quite busy with block out r=
ates
in vmstat of merely a few thousands at maximum.

Thus I suspect fragmentation of btrfs trees or files.

The filesystems has the following specifics - apt-get will work on / on=
ly
obviously:

deepdance:~> btrfs filesystem show
failed to read /dev/sr0
Label: 'debian'  uuid: 2bf5b1dc-1d89-4f0d-a561-1a5551a27275
        Total devices 1 FS bytes used 7.34GB
        devid    1 size 15.00GB used 14.97GB path /dev/dm-0

Label: 'home'  uuid: a600de65-e1ab-4cbf-b150-bbaeaf9fa98d
        Total devices 1 FS bytes used 28.13GB
        devid    1 size 80.00GB used 40.54GB path /dev/dm-2

Btrfs Btrfs v0.19
deepdance:~> btrfs filesystem df /
Data: total=3D11.23GB, used=3D6.84GB
System, DUP: total=3D8.00MB, used=3D4.00KB
System: total=3D4.00MB, used=3D0.00
Metadata, DUP: total=3D1.86GB, used=3D510.99MB

I cleaned out a lot of packages due to the slow dist-upgrades already
and also cause I do not need them on that laptop anymore. Thus the
data tree only uses half of the allocated space. BTRFS doesn=B4t seem
to give space back to the pool for all trees. Maybe it will do that
on btrfs filesystem balance?

home is:

deepdance:~> btrfs filesystem df /home
Data: total=3D37.01GB, used=3D27.54GB
System, DUP: total=3D8.00MB, used=3D12.00KB
System: total=3D4.00MB, used=3D0.00
Metadata, DUP: total=3D1.75GB, used=3D598.76MB
Metadata: total=3D8.00MB, used=3D0.00
deepdance:~>

BTW why does it have two metadata and systems trees while /
only have one?

Currently I have:

deepdance:~> cat /proc/version
Linux version 3.0.0-2-686-pae (Debian 3.0.0-6) (ben@decadent.org.uk)
(gcc version 4.5.3 (Debian 4.5.3-9) ) #1 SMP Wed Nov 2 05:29:50
UTC 2011

from Debian Wheezy.

=46ree memory is quite okay:

deepdance:~> free -m
             total       used       free     shared    buffers     cach=
ed
Mem:           755        699         55          0          0        3=
47
-/+ buffers/cache:        352        402
Swap:         2047        148       1899

I am wondering on how to optimize performance on the /
BTRFS filesystem.

I am not sure whether to try btrfs filesystem balance or
btrfs filesystem defragment /.

I also wonder whether some Debian package management related
file might be fragmented. But the ones I tested do not seem to be:

deepdance:/var/lib/dpkg> filefrag available
available: 1 extent found
deepdance:/var/lib/dpkg> filefrag status  =20
status: 1 extent found
deepdance:/var/lib/dpkg>

But then I also do not know whether "filefrag" from "e2fsprogs"=20
1.42~WIP-2011-10-16-1 will work with BTRFS.

Any advice?

Its not critical for me to fix these issues (soon), but I am curious
whether its possible to get the filesystem speedier by some
maintenance.

Thanks,
--=20
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
--
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

^ permalink raw reply	[flat|nested] 24+ messages in thread
* Re: speeding up slow btrfs filesystem
@ 2011-12-17 11:54 Martin Steigerwald
  2011-12-17 12:02 ` Martin Steigerwald
  2011-12-17 12:50 ` Goffredo Baroncelli
  0 siblings, 2 replies; 24+ messages in thread
From: Martin Steigerwald @ 2011-12-17 11:54 UTC (permalink / raw)
  To: Goffredo Baroncelli, linux-btrfs

Am Samstag, 17. Dezember 2011 schrieben Sie:
> On Friday, 16 December, 2011 20:53:58 Martin Steigerwald wrote:
> > > I found a solution, but requires a bit of setup.
> > >=20
> > >=20
> > >=20
> > > The idea is to avoid do perform sync during the package
> > > installation. In order to avoid data loss in case of failure, I
> > > create a snapshot before the upgrading. If something goes wrong
> > > (i.e. a power failure) I rebooot the system from the snapshot. If
> > > the installation finish without problem, I flush all the data to
> > > the disk and remove the snapshot.
> > >=20
> > >=20
> > >=20
> > > For the detail, see a my old post titled "[RFC] aptitude & BTRFS
> > > slow" (2011-10-19)
> >=20
> > Sounds more like a workaround to me than a solution.
>=20
> Sorry but I strongly disagree.
>=20
> Aptitude was designed for an ordinary filesystem. Where the only way =
to
> have a filesystem consistency is to issue a lot of sync for every
> package. But this doesn't prevent to have an half package
> installed:(think about to an "openoffice" upgrade: in case of power
> failure, you could not have nor the old openoffice, nor the new one.
> Instead with the snapshot you can always have the old system or the n=
ew
> system. No half packages
>=20
> With BTRFS, I can say that the workaround[*] is using the sync and no=
t
> the snapshot
>=20
> The true is that BTRFS is different from ext4 (or ext3, xfs....). You
> can use BTRFS like ext4 and you will find a lot of regression like
> this.
>=20
> BTRFS is very different from an ordinary filesystem, and you have to
> change some behaviour to take advantages with is peculiarities.

This reminds me of the delayed allocation discussion as Ext4 introduced=
=20
that feature.

Ext3/4 developer Theodore T=C2=B4so  said if the applications are not u=
sing=20
fsync() its their fault. But before OTOH applications began to avoid us=
ing=20
fsync() since it has had serious performance drawbacks on ext3 (not ext=
4)=20
with data=3Dordered.=20

Ext4 now has workarounds for the rename and truncate cases, after Linus=
=20
requested boldly to not break existing userspace.

Now applications that use fsync() the way Theodore T=C2=B4so and other =
see it=20
correctly used should now skip the fsync() on a BTRFS?

I find it *highly* problematic when applications are required to adapt=20
their behavior depending of the filesystem being in use.

This just doesn=C2=B4t make sense to me.

If BTRFS has other means to guarantee filesystem consistency that is fa=
ster=20
it might still make fsync() a no-op or just creating a snapshot=20
temporarily automatically.

> Using the snapshot during an upgrade open a lot of possibility which
> are not allowed with EXT4. With snapshot you can always go back if
> during an upgrade if something goes wrong (like strange packages
> dependencies). Or you can have the previous configuration to go back
> in case of trouble.

Adding new possibilities is one thing. And supporting snapshots properl=
y=20
would depend on some support side from the applications. I think that=20
using snapshots for upgrades is a good idea.

But OTOH I think that BTRFS should not break or slow down existing=20
userspace. I think that existing approaches like using fsync() like=20
according to quite some filesystem developers it should be used should=20
continue to work nicely.

Similar goes for the hardlink limit.

> [*] Of course this is due to the fact that the most part of the
> filesystem is like ext4. Supporting BTRFS could be not the highest
> priority.

I do think that a

if fs=3Dext4 then do this

if fs=3Dbtrfs then do this and

if fs=3Dext3 + data=3Dordered then do this

if fs=3Dext3 + data=3Dordered + kernel=3Dwhatnot then do it a tad bit d=
ifferently

if fs=3Dunkown then assume this

in a application is just kind about broken and always thought that one=20
main task of a filesystem would be to lift off the burden on the detail=
s on=20
how data is saved from the application.

Ok, some guidelines might be needed like if you save 10 bytes 1000 time=
s=20
it might be less performant than saving 10000 bytes at once, but aside=20
from that=E2=80=A6

So I think BTRFS should have a fast fsync - that fullfils the consisten=
cy=20
guarentee by whatever compatible way it sees fit - and for the system=20
partition I would even trade in the cow functionality. I didn=C2=B4t ha=
ve it=20
with Ext4 anyway.

Thanks,
--=20
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
--
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

^ permalink raw reply	[flat|nested] 24+ messages in thread
end of thread, other threads:[~2011-12-20 19:46 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-12-16 17:51 speeding up slow btrfs filesystem Martin Steigerwald
2011-12-16 17:54 ` Martin Steigerwald
2011-12-16 18:38   ` Goffredo Baroncelli
2011-12-16 19:53     ` Martin Steigerwald
2011-12-16 20:58       ` Martin Steigerwald
2011-12-17  7:03         ` Sergei Trofimovich
2011-12-17 11:09           ` Martin Steigerwald
2011-12-17 11:26             ` Hugo Mills
2011-12-17 11:38               ` Martin Steigerwald
2011-12-17 11:45                 ` Hugo Mills
2011-12-17 11:57                   ` Martin Steigerwald
2011-12-17 16:35                   ` Martin Steigerwald
2011-12-17 17:27                     ` Hugo Mills
2011-12-17 11:39       ` Goffredo Baroncelli
2011-12-18 18:41     ` Andrea Gelmini
2011-12-20 19:46       ` Goffredo Baroncelli
2011-12-17 11:11 ` Chris Samuel
2011-12-17 12:00   ` Martin Steigerwald
2011-12-17 12:42     ` David McBride
2011-12-17 16:14       ` Martin Steigerwald
2011-12-17 11:54 Martin Steigerwald
2011-12-17 12:02 ` Martin Steigerwald
2011-12-17 12:50 ` Goffredo Baroncelli
2011-12-17 16:10   ` Martin Steigerwald

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.