On Mon, Apr 17, 2017 at 1:26 PM, Austin S. Hemmelgarn <ahferro...@gmail.com> wrote: > On 2017-04-17 14:34, Chris Murphy wrote:
>> Nope. The first paragraph applies to NVMe machine with ssd mount >> option. Few fragments. >> >> The second paragraph applies to SD Card machine with ssd_spread mount >> option. Many fragments. > > Ah, apologies for my misunderstanding. >> >> >> These are different versions of systemd-journald so I can't completely >> rule out a difference in write behavior. > > There have only been a couple of changes in the write patterns that I know > of, but I would double check that the values for Seal and Compress in the > journald.conf file are the same, as I know for a fact that changing those > does change the write patterns (not much, but they do change). Same, unchanged defaults on both systems. #Storage=auto #Compress=yes #Seal=yes #SplitMode=uid #SyncIntervalSec=5m #RateLimitIntervalSec=30s #RateLimitBurst=1000 The sync interval sec is curious. 5 minutes? Umm, I'm seeing nearly constant hits every 2-5 seconds on the journal file; using filefrag. I'm sure there's a better way to trace a single file being read/written to than this, but... >>>> It's almost like we need these things to not fsync at all, and just >>>> rely on the filesystem commit time... >>> >>> >>> Essentially yes, but that causes all kinds of other problems. >> >> >> Drat. >> > Admittedly most of the problems are use-case specific (you can't afford to > lose transactions in a financial database for example, so it functionally > has to call fsync after each transaction), but most of it stems from the > fact that BTRFS is doing a lot of the same stuff that much of the 'problem' > software is doing itself internally. > Seems like the old way of doing things, and the staleness of the internet, have colluded to create a lot of nervousness and misuse of fsync. The very fact Btrfs needs a log tree to deal with fsync's in a semi-sane way... -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
