Re: BTRFS setup advice for laptop performance ?

["Swâmi Petaramesh" <swami@petaramesh.org>]

[-- Attachment #1: Type: text/plain, Size: 3708 bytes --]

Hi people :-)

Le samedi 5 avril 2014 15:13:40 Hugo Mills a écrit :
> 
>  - I'm not aware, particularly, of any major differences between
>    noatime and relatime in performance on btrfs. (But I may be wrong
>    there).

It's especially noticeable at first boot in a given day, as "relatime" will 
have atimes updated once a day.

I've noticed that the 1st boot on any given day can be up to 3-4 times longer 
on a BTRFS with "relatime" compared to a btrfs with "noatime". This is 
especially true if snapshots have recently been made.

>  - Given Duncan's discussion of the performance of the semantic
>    desktop, I would suggest turning it off *temporarily* to see if it
>    really is where the difficulty lies.

I'm afraid that this would turn my email off (I used Kmail and it's backing 
store is Akonadi, and non, I don't want to change MUA), and I can't really 
live long without it ;-)

>    (maybe delete the database and rebuild it regularly?

I'm not considering deleting the database. It contains about 1GB of my email 
archive and I've no clue about how I could possibly export and reimport it. 
The way the Kmail apps use the Akonadi backing store is somewhat tricky...

>    mark parts of it nodatacow?

I woud be allright about trying "nodatacow", but it's totally unclear to me 
what impact this can have on snapshots ?

Will "nodatacow" defeat snapshots, allowing data to change in snapshots ?

OTOH will snapshots force datacow to happen, defeating the purpose of 
nodatacow ?

As I don't want to break my DB, I won't use nodatacow until I'm sure about the 
consequences...

>    maybe autodefrag helps?

I've always used autodefrag... Plus I perform manual defrags more often than 
in Windows :-/

>    maybe it's something simple
>    the authors of the database can change?).

I'm not going to expect KDE people to change anything aytime soon upon users 
requests. Some very *SIMPLE* bugs confirmed by dozens of users have stayed in 
their bug tracker for years.

KDE bugs stay until somedays God decides to fix one. If ever.

>    If you truly find btrfs unusable -- which you've said at various
> points in the past -- then I'm not going to suggest that you keep
> using it. Maybe something else is genuinely better for you.

Every 9 months or so I reads reports or reviews or the BTRFS wiki stating that 
performance and stability of BTRFS have dramatically improved. Then I read 
everyting I can about new mkfs or btrfstune options, advice, best mount 
options, the wiki, and give it a try.

Typically a couple months later my machines slow down to the point where I 
come and start complaining here.

Usually 2 more months and I'm back either to ext4 or ZFS, depending on the 
machine's specific usage pattern...

I still think that BTRFS *should* be very promising *if* its developpers can 
fix the recurring performance issues and make it truly usable « for basic 
boring office use » which is currently typically my case on my laptops, and I'm 
no benchmark (or maybe a human one ?) and I can say that currently, BTRFS is 
*not* adapted for a KDE desktop running KMail and Firefox - but if it aint' no 
good at this very basic usage, well what is it good at ?

I'm not ranting because I love to shoot BTRFS down in flames, but because I'd 
love to be able to keep it on my system this time, and forget it, and not to 
reformat everything again in a month or so (as soon as I will tell myself : « 
Well, the improvements promised by kernel 3.14 are still far behind my 
usability needs »)...

Kind regards.

-- 
Swâmi Petaramesh <swami@petaramesh.org> http://petaramesh.org PGP 9076E32E

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 190 bytes --]