> I suggest you start by reading > http://www.mail-archive.com/linux-btrfs@xxxxxxxxxxxxxxx/msg18827.html > > After that, PROBABLY start your database by preloading libeatmydata to > disable fsync completely. Which will cure the sympthoms, not the issue itself - I remember the same advice was given for Reiser4 back then ;) Usually for non-toy use-cases data is too valueable to just disable fsync. - Clemens 2012/10/1 Fajar A. Nugraha <list@xxxxxxxxx>: > On Mon, Oct 1, 2012 at 8:27 PM, Cesar Inacio Martins > <cesar_inacio_martins@xxxxxxxxxxxx> wrote: > >> My problem: >> * Using btrfs + compression , flush of 60 MB/s take 4 minutes.... >> (on this 4 minutes they keep constatly I/O of +- 4MB/s no disks) >> (flush from Informix database) > > >> * OpenSuse 12.1 64bits, running over VmWare ESXi 5 >> * Btrfs version : btrfsprogs-0.19-43.1.2.x86_64 >> * Kernel : Linux jdivm06 3.1.10-1.16-desktop #1 SMP PREEMPT Wed Jun 27 > > >> My question, what I believed will help to avoid this long flush : >> * Have some way to force this flush all in memory cache and then use the >> btrfs background process to flush to disk ... >> Security and recover aren't a priority for now, because this is part of a >> database bulkload ...after finish , integrity will be desirable (not a >> obligation, since this is a test environment) >> >> For now, performance is the mainly requirement... > > > I suggest you start by reading > http://www.mail-archive.com/linux-btrfs@xxxxxxxxxxxxxxx/msg18827.html > > After that, PROBABLY start your database by preloading libeatmydata to > disable fsync completely. > > On a side note, zfs has "sync" property, which when set to "disabled", > have pretty much the same effect as libeatmydata. > > -- > Fajar > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
