Mailinglist Archive: opensuse (1470 mails)

< Previous Next >
Re: [opensuse] Why Is Leap 42.1 Benchmarking Poorly?
On Thu, Feb 25, 2016 at 2:56 PM, Vojtěch Zeisek
<vojtech.zeisek@xxxxxxxxxxxx> wrote:
Dne Čt 25. února 2016 14:40:00, Andrei Borzenkov napsal(a):
On Thu, Feb 25, 2016 at 2:28 PM, Vojtěch Zeisek
<vojtech.zeisek@xxxxxxxxxxxx> wrote:
Copy-on-write is terribly slowing down any DB.

btrfs does not do any copy on write. It does "redirect on write" which

https://btrfs.wiki.kernel.org/index.php/Main_Page „Btrfs is a new copy on
write (CoW) filesystem for Linux...“ Did I misunderstand something? :-)


No; whoever created this page used confusing name. CoW snapshots
existed long before btrfs was invented and has quite precise meaning
in storage world - it is technology when old data is *copied*
elsewhere before being overwritten by new data in place. btrfs does
not overwrite old data ever - new data is written in free space,
leaving old intact. This applies not only to user data, but to
metadata as well - so you get completely new filesystem tree, and only
when this tree is constructed, the top level pointer is "flipped".

is quite different. This does cause fragmentation; it is impossible to
give blanket statement what effect it will have. It will likely impact
sequential IO; it is much less likely impact random IO (unless your
database is very small and would not be affected by seek latency
otherwise).

I don't know the theoretical background. But many tests show Btrfs with CoW
and subvolumes has bad performance impact to DB. See also
https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Copy_on_Write_.28CoW.29

Also snapshots don't make sense
for DB (use DB's tools).

If you have suggestions how to make point in time online copies
without impacting normal activity (terribly slowing down client access

Client access is what is counted, right? ;-)


Is it sarcasm? Database exists to serve clients and if clients are cut
off for hours or days to perform backup, then yes, it counts. Or if
clients must wait for days to revert to older date because someone
made an error.

:) ) *and* revert to them in seconds for multiterabyte database (in
order of several dozens TB) without using snapshots I am all ears.

I don't say it is a bug. It just isn't the best for all user cases...

You said "it does not make sense". It is very far from "isn't the best
in all user cases".
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups