On 2/7/17 8:53 AM, Peter Zaitsev wrote: > Hi, > > I have tried BTRFS from Ubuntu 16.04 LTS for write intensive OLTP MySQL > Workload. > > It did not go very well ranging from multi-seconds stalls where no > transactions are completed to the finally kernel OOPS with "no space left > on device" error message and filesystem going read only. > > I'm complete newbie in BTRFS so I assume I'm doing something wrong. > > Do you have any advice on how BTRFS should be tuned for OLTP workload > (large files having a lot of random writes) ? Or is this the case where > one should simply stay away from BTRFS and use something else ? > > One item recommended in some places is "nodatacow" this however defeats > the main purpose I'm looking at BTRFS - I am interested in "free" > snapshots which look very attractive to use for database recovery scenarios > allow instant rollback to the previous state. >
Hi Peter - There seems to be some misunderstanding around how nodatacow works. Nodatacow doesn't prohibit snapshot use. Snapshots are still allowed and, of course, will cause CoW to happen when a write occurs, but only on the first write. Subsequent writes will not CoW again. This does mean you don't get CRC protection for data, though. Since most databases do this internally, that is probably no great loss. You will get fragmentation, but that's true of any random-write workload on btrfs. Timothy's comment about how extents are accounted is more-or-less correct. The file extents in the file system trees reference data extents in the extent tree. When portions of the data extent are unreferenced, they're not necessarily released. A balance operation will usually split the data extents so that the unused space is released. As for the Oopses with ENOSPC, that's something we'd want to look into if it can be reproduced with a more recent kernel. We shouldn't be getting ENOSPC anywhere sensitive anymore. -Jeff -- Jeff Mahoney SUSE Labs
signature.asc
Description: OpenPGP digital signature
