speeding up slow btrfs filesystem
Am Samstag, 17. Dezember 2011 schrieben Sie:
Quoted 16 lines · On Friday, 16 December, 2011 20:53:58 Martin Steigerwald wrote:
Quoted 15 lines
Quoted 15 lines
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)
Quoted 6 lines
Quoted 2 lines
=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
Quoted 5 lines
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
Quoted 3 lines
system. No half packages
=20
With BTRFS, I can say that the workaround[*] is using the sync and no=
t
Quoted 8 lines
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=20fsync() its their fault. But before OTOH applications began to avoid us= ing=20fsync() 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.
Quoted 5 lines
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.
Quoted 3 lines
[*] 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Samstag, 17. Dezember 2011 schrieb Martin Steigerwald:
Quoted 3 lines
If BTRFS has other means to guarantee filesystem consistency that is faster it might still make
fsync()a no-op or just creating a snapshot temporarily automatically.
To clear this up: It should only make it a no-op if it guarentees the consistency without it. Otherwise it should do whatever is necessary to guarantee it.
Signature · 2 lines
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
On Saturday, 17 December, 2011 12:54:47 you wrote:
[...]
Quoted 2 lines
=20
This reminds me of the delayed allocation discussion as Ext4 introduc=
ed
Quoted 3 lines
that feature.
=20
Ext3/4 developer Theodore T=B4so said if the applications are not us=
ing
Quoted 1 line
fsync()its their fault. But before OTOH applications began to avoid =
using
Quoted 1 line
fsync()since it has had serious performance drawbacks on ext3 (not e=
xt4)
Quoted 3 lines
with data=3Dordered.
=20
Ext4 now has workarounds for the rename and truncate cases, after Lin=
us
Quoted 1 line
requested boldly to not break existing userspace.
IIRC the problem was data loss. Instead you was blaming (correctly) a s= lowness=20
problem. Are two very different problem.
Quoted 1 line
Now applications that use
fsync()the way Theodore T=B4so and other s=
ee it
Quoted 1 line
correctly used should now skip the
fsync()on a BTRFS?
I never say to not use the fsync() call. I am only arguing that for a p= ackage=20
manager the fsync() call is not the best API.=20
The package manager were designed with capabilities of the old file-sys= tems in=20
mind. At the time the sync(2) API was the only available. With this API it is impossible to have an atomic upgrade (all or nothin=
g) of a=20
package.=20
With the new filesystems (BTRFS and ZFS ), the package manager have mor= e=20
options. They can create a snapshot at the beginning (of the old filesy= stem)=20
and rollback if something goes wrong (I am simplifying a bit) . But the= =20
package manager have to be updated.
As bonus you can avoid to use sync(2) which has performance drawbacks=20 (specially with BTRFS).
=20
[...]
Quoted 2 lines
=20
Quoted 1 line
Using the snapshot during an upgrade open a lot of possibility whic=
h
Quoted 3 lines
Quoted 3 lines
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 bac=
k
Quoted 3 lines
Quoted 1 line
in case of trouble.
=20
Adding new possibilities is one thing. And supporting snapshots prope=
rly
Quoted 6 lines
would depend on some support side from the applications. I think that using snapshots for upgrades is a good idea.
=20
But OTOH I think that BTRFS should not break or slow down existing userspace. I think that existing approaches like usingfsync()like according to quite some filesystem developers it should be used shoul=
d
Quoted 1 line
continue to work nicely.
Nobody wants to slowdown the application. But the life is full of compr= omises.
If you want the speed of ext4, you can use ext4. If you want the snapsh= ot=20
capability and the COW guarantee you can use BTRFS, but you have some=20 slowness.
Of course the best would be have the speed of the ext4 with the capabil= ities=20
of btrfs.... :-) Unfortunately today this is not available.
[....]
Quoted 2 lines
=20
Thanks,
Regards
--=20
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijack@inwi= nd.it>
Key fingerprint =3D 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 --
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Samstag, 17. Dezember 2011 schrieb Goffredo Baroncelli:
Quoted 10 lines
Quoted 10 lines
Adding new possibilities is one thing. And supporting snapshots properly would depend on some support side from the applications. I think that using snapshots for upgrades is a good idea.
=20
But OTOH I think that BTRFS should not break or slow down existing userspace. I think that existing approaches like using
fsync()like according to quite some filesystem developers it should be used should continue to work nicely.
Quoted 9 lines
=20
Nobody wants to slowdown the application. But the life is full of compromises. If you want the speed of ext4, you can use ext4. If you want the snapshot capability and the COW guarantee you can use BTRFS, but you have some slowness.
=20
Of course the best would be have the speed of the ext4 with the capabilities of btrfs.... :-) Unfortunately today this is not available.
Its perfectly acceptable for me that BTRFS does not deliver this yet.
I understood your initial answer that its just that BTRFS is different = and=20
thus performs poorly in fsync() based workloads and thats about it. Tha= t=20
its a principal issue. That part I didn=B4t agree too. Heck from the de= sign=20
differences of COW filesystem it might even be some sort of a principal= =20
issue. But then I like to see this as a challenge, not as a show stoppe= r.
Actually for me especially for that Amarok Thinkpad T23 there is no hur= ry.=20
Its play BTRFS play machine. I just want to see what I can do with=20 filesystem maintenance to bring it up to speed.
Everything else is following development and upgrading kernels ;).
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html