Btrfs devel - Mar 2013 - zlib vs lzo uncompress speed, ssd vs nossd

I just setup a new SSD with my laptop root filesystem, and at the time I
though, "eh, I''ll just use zlib compression during the first copy,
and then
switch to lzo afterwards to maintain write speed when I''m using the
laptop
after the copy and reboot".

Now, I rebooted with the new ssd and zlib compressed rootfs, and it seemed
to boot slower than it did before with the same root files on btrfs lzo.

My mount options are back to lzo:
/dev/mapper/cryptroot / btrfs rw,noatime,compress=lzo,nossd,discard,space_cache
0 0

Is my feeling of slower boot wrong, or is zlib also noticeably slower than
lzo to read and decompress?

And separately, back a while ago, I read in multiple places that
''nossd''
actually worked better than ''ssd''. This was over a year ago
now.

What''s the current consensus on ssd and nosdd?
Am I correct that it mostly affects how data is layed out at write time by
btrfs?
Should I go back to trying ssd instead of nossd?

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" -
A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  
--
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

On Wed, Mar 27, 2013 at 11:53 AM, Marc MERLIN <marc@merlins.org>
wrote:
>
> Is my feeling of slower boot wrong, or is zlib also noticeably slower than
> lzo to read and decompress?
>
Lzo compression should be faster in every aspect than zlib, especially
for reading.

But having said that, btrfs won''t recompress any existing files just
because you switch your mount option from lzo to zlib.  Only newly
written files will be zlib, and btrfs will leave the lzo-compressed
files alone unless they are re-written, or you expressly recompress
them using the defrag tool.

If you were to take a snapshot of your root partition, and reboot to
the snapshot as the new root with zlib compression, you could make
some side-by-side comparisons of boot time to clarify your
impressions.
--
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

On Wed, Mar 27, 2013 at 04:12:27PM -0500, Mitch Harder
wrote:
> On Wed, Mar 27, 2013 at 11:53 AM, Marc MERLIN <marc@merlins.org>
wrote:
> >
> > Is my feeling of slower boot wrong, or is zlib also noticeably slower
than
> > lzo to read and decompress?
> >
> 
> Lzo compression should be faster in every aspect than zlib, especially
> for reading.
> 
> But having said that, btrfs won''t recompress any existing files
just
> because you switch your mount option from lzo to zlib.  Only newly
> written files will be zlib, and btrfs will leave the lzo-compressed
> files alone unless they are re-written, or you expressly recompress
> them using the defrag tool.
 
That was my intent at the time, I thought that zlib decompression was about
as fast as lzo, so it would have been good that most my files stayed
compressed as zlib.
Turns out I was wrong :)
> If you were to take a snapshot of your root partition, and reboot to
> the snapshot as the new root with zlib compression, you could make
> some side-by-side comparisons of boot time to clarify your
> impressions.
Fair point. By that, you mean degrag all my files somehow (recompressing as
lzo, and doubling the size of my rootfs)?

Also, I was re-reading ssd vs nossd:
https://btrfs.wiki.kernel.org/index.php/Mount_options
isn''t clear whether these are read/write ordering optimizations, or
filesystem layout optimization (i.e. you''d have to recreate the entire
FS,
and rewrite everything).

http://www.phoronix.com/scan.php?page=article&item=btrfs_ssd_mode&num=1
says ''However, unless disabling the write cache for the drive, the SSD
mode
does not necessarily mean better performance. In fact, as our results are
about to show, the quantitative disk performance can drop greatly in the SSD
mode when the write cache remains enabled''
But that''s from 2009, so not very relevant to today.

Do you happen to know more than me on this?

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" -
A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  
--
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

On Wed, Mar 27, 2013 at 04:12:27PM -0500, Mitch Harder
wrote:
> Lzo compression should be faster in every aspect than zlib, especially
> for reading.
Speaking of which, it would be awesome if there were a some chattr option to
choose which encryption you''d like for a file or a subdirectory tree
(compress this tree as much as you can, but use fast lzo for that tree).
But I agree that would be lower on the priority list, and the chattr
interface likely doesn''t make that easy.

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" -
A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  
--
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

On Wed, Mar 27, 2013 at 4:22 PM, Marc MERLIN <marc@merlins.org>
wrote:
> On Wed, Mar 27, 2013 at 04:12:27PM -0500, Mitch Harder wrote:
>> On Wed, Mar 27, 2013 at 11:53 AM, Marc MERLIN <marc@merlins.org>
wrote:
>> >
>> > Is my feeling of slower boot wrong, or is zlib also noticeably
slower than
>> > lzo to read and decompress?
>> >
>>
>> Lzo compression should be faster in every aspect than zlib, especially
>> for reading.
>>
>> But having said that, btrfs won''t recompress any existing
files just
>> because you switch your mount option from lzo to zlib.  Only newly
>> written files will be zlib, and btrfs will leave the lzo-compressed
>> files alone unless they are re-written, or you expressly recompress
>> them using the defrag tool.
>
> That was my intent at the time, I thought that zlib decompression was about
> as fast as lzo, so it would have been good that most my files stayed
> compressed as zlib.
> Turns out I was wrong :)
>
>> If you were to take a snapshot of your root partition, and reboot to
>> the snapshot as the new root with zlib compression, you could make
>> some side-by-side comparisons of boot time to clarify your
>> impressions.
>
> Fair point. By that, you mean degrag all my files somehow (recompressing as
> lzo, and doubling the size of my rootfs)?
>
> Also, I was re-reading ssd vs nossd:
> https://btrfs.wiki.kernel.org/index.php/Mount_options
> isn''t clear whether these are read/write ordering optimizations,
or
> filesystem layout optimization (i.e. you''d have to recreate the
entire FS,
> and rewrite everything).
>
>
http://www.phoronix.com/scan.php?page=article&item=btrfs_ssd_mode&num=1
> says ''However, unless disabling the write cache for the drive, the
SSD mode
> does not necessarily mean better performance. In fact, as our results are
> about to show, the quantitative disk performance can drop greatly in the
SSD
> mode when the write cache remains enabled''
> But that''s from 2009, so not very relevant to today.
>
> Do you happen to know more than me on this?
>
I''m sorry, I have no experience with the ssd mount option.
--
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