1. 09 Sep, 2024 30 commits
  2. 04 Sep, 2024 1 commit
  3. 01 Sep, 2024 1 commit
  4. 31 Aug, 2024 2 commits
    • Kent Overstreet's avatar
      bcachefs: Mark more errors as autofix · 3d3020c4
      Kent Overstreet authored
      errors that are known to always be safe to fix should be autofix: this
      should be most errors even at this point, but that will need some
      thorough review.
      
      note that errors are still logged in the superblock, so we'll still know
      that they happened.
      Signed-off-by: default avatarKent Overstreet <kent.overstreet@linux.dev>
      3d3020c4
    • Kent Overstreet's avatar
      bcachefs: Revert lockless buffered IO path · e3e69409
      Kent Overstreet authored
      We had a report of data corruption on nixos when building installer
      images.
      
      https://github.com/NixOS/nixpkgs/pull/321055#issuecomment-2184131334
      
      It seems that writes are being dropped, but only when issued by QEMU,
      and possibly only in snapshot mode. It's undetermined if it's write
      calls are being dropped or dirty folios.
      
      Further testing, via minimizing the original patch to just the change
      that skips the inode lock on non appends/truncates, reveals that it
      really is just not taking the inode lock that causes the corruption: it
      has nothing to do with the other logic changes for preserving write
      atomicity in corner cases.
      
      It's also kernel config dependent: it doesn't reproduce with the minimal
      kernel config that ktest uses, but it does reproduce with nixos's distro
      config. Bisection the kernel config initially pointer the finger at page
      migration or compaction, but it appears that was erroneous; we haven't
      yet determined what kernel config option actually triggers it.
      
      Sadly it appears this will have to be reverted since we're getting too
      close to release and my plate is full, but we'd _really_ like to fully
      debug it.
      
      My suspicion is that this patch is exposing a preexisting bug - the
      inode lock actually covers very little in IO paths, and we have a
      different lock (the pagecache add lock) that guards against races with
      truncate here.
      
      Fixes: 7e64c86c ("bcachefs: Buffered write path now can avoid the inode lock")
      Signed-off-by: default avatarKent Overstreet <kent.overstreet@linux.dev>
      e3e69409
  5. 27 Aug, 2024 2 commits
    • Kent Overstreet's avatar
      bcachefs: Fix bch2_extents_match() false positive · d2693569
      Kent Overstreet authored
      This was caught as a very rare nonce inconsistency, on systems with
      encryption and replication (and tiering, or some form of rebalance
      operation running):
      
      [Wed Jul 17 13:30:03 2024] about to insert invalid key in data update path
      [Wed Jul 17 13:30:03 2024] old: u64s 10 type extent 671283510:6392:U32_MAX len 16 ver 106595503: durability: 2 crc: c_size 8 size 16 offset 0 nonce 0 csum chacha20_poly1305_80 compress zstd ptr: 3:355968:104 gen 7 ptr: 4:513244:48 gen 6 rebalance: target hdd compression zstd
      [Wed Jul 17 13:30:03 2024] k:   u64s 10 type extent 671283510:6400:U32_MAX len 16 ver 106595508: durability: 2 crc: c_size 8 size 16 offset 0 nonce 0 csum chacha20_poly1305_80 compress zstd ptr: 3:355968:112 gen 7 ptr: 4:513244:56 gen 6 rebalance: target hdd compression zstd
      [Wed Jul 17 13:30:03 2024] new: u64s 14 type extent 671283510:6392:U32_MAX len 8 ver 106595508: durability: 2 crc: c_size 8 size 16 offset 0 nonce 0 csum chacha20_poly1305_80 compress zstd ptr: 3:355968:112 gen 7 cached ptr: 4:513244:56 gen 6 cached rebalance: target hdd compression zstd crc: c_size 8 size 16 offset 8 nonce 0 csum chacha20_poly1305_80 compress zstd ptr: 1:10860085:32 gen 0 ptr: 0:17285918:408 gen 0
      [Wed Jul 17 13:30:03 2024] bcachefs (cca5bc65-fe77-409d-a9fa-465a6e7f4eae): fatal error - emergency read only
      
      bch2_extents_match() was reporting true for extents that did not
      actually point to the same data.
      
      bch2_extent_match() iterates over pairs of pointers, looking for
      pointers that point to the same location on disk (with matching
      generation numbers). However one or both extents may have been trimmed
      (or merged) and they might not have the same disk offset: it corrects
      for this by subtracting the key offset and the checksum entry offset.
      
      However, this failed when an extent was immediately partially
      overwritten, and the new overwrite was allocated the next adjacent disk
      space.
      
      Normally, with compression off, this would never cause a bug, since the
      new extent would have to be immediately after the old extent for the
      pointer offsets to match, and the rebalance index update path is not
      looking for an extent outside the range of the extent it moved.
      
      However with compression enabled, extents take up less space on disk
      than they do in the btree index space - and spuriously matching after
      partial overwrite is possible.
      
      To fix this, add a secondary check, that strictly checks that the
      regions pointed to on disk overlap.
      
      https://github.com/koverstreet/bcachefs/issues/717Signed-off-by: default avatarKent Overstreet <kent.overstreet@linux.dev>
      d2693569
    • Kent Overstreet's avatar
      bcachefs: Fix failure to return error in data_update_index_update() · 66927b89
      Kent Overstreet authored
      This fixes an assertion pop in io_write.c - if we don't return an error
      we're supposed to have completed all the btree updates.
      Signed-off-by: default avatarKent Overstreet <kent.overstreet@linux.dev>
      66927b89
  6. 24 Aug, 2024 2 commits
  7. 22 Aug, 2024 2 commits