* [PATCH] btrfs: test an incremental send scenario with hole punching @ 2026-10-21 20:17 fdmanana 2026-11-12 17:12 ` Johannes Thumshirn 2026-11-14 15:05 ` Zorro Lang 0 siblings, 2 replies; 5+ messages in thread From: fdmanana @ 2026-10-21 20:17 UTC (permalink / raw) To: fstests; +Cc: linux-btrfs, Filipe Manana From: Filipe Manana <fdmanana@suse.com> Test an incremental send scenario where we punched a hole into a tail section of a file extent item that is the last item in a leaf and the next leaf in the subvolume tree was not changed (remains shared between the parent and send snapshots). This currently fails and is fixed by the following kernel patch: btrfs: send: fix missing hole punching during incremental send Signed-off-by: Filipe Manana <fdmanana@suse.com> --- tests/btrfs/362 | 84 +++++++++++++++++++++++++++++++++++++++++++++ tests/btrfs/362.out | 7 ++++ 2 files changed, 91 insertions(+) create mode 100755 tests/btrfs/362 create mode 100644 tests/btrfs/362.out diff --git a/tests/btrfs/362 b/tests/btrfs/362 new file mode 100755 index 00000000..aca56540 --- /dev/null +++ b/tests/btrfs/362 @@ -0,0 +1,84 @@ +#! /bin/bash +# SPDX-License-Identifier: GPL-2.0 +# Copyright (c) 2026 SUSE S.A. All Rights Reserved. +# +# FS QA Test 362 +# +# Test an incremental send scenario where we punched a hole into a tail section +# of a file extent item that is the last item in a leaf and the next leaf in the +# subvolume tree was not changed (remains shared between the parent and send +# snapshots). +# +. ./common/preamble +_begin_fstest auto quick send + +_cleanup() +{ + cd / + rm -fr $tmp.* + rm -fr $send_files_dir +} + +. ./common/filter + +_require_test +_require_scratch +_require_btrfs_support_sectorsize 4096 +_require_xfs_io_command "fpunch" + +_fixed_by_kernel_commit xxxxxxxxxx \ + "btrfs: send: fix missing hole punching during incremental send" + +send_files_dir=$TEST_DIR/btrfs-test-$seq + +rm -fr $send_files_dir +mkdir $send_files_dir + +first_stream="$send_files_dir/1.send" +second_stream="$send_files_dir/2.send" + +# We need a very specific leaf layout where we punch a hole in the last file +# extent item of a leaf and the next leaf was not modified in the send snapshot, +# so we set a fixed size of 16K. +_scratch_mkfs -n 16K >> $seqres.full 2>&1 || _fail "first mkfs failed" +_scratch_mount + +touch $SCRATCH_MNT/foo +# 205 extents of 64K each with a 64K hole between them. +for ((i = 0; i < 410; i += 2)); do + offset=$((i * 64 * 1024)) + $XFS_IO_PROG -c "pwrite -b 64K -S 0xab $offset 64K" \ + $SCRATCH_MNT/foo > /dev/null +done + +_btrfs subvolume snapshot -r $SCRATCH_MNT $SCRATCH_MNT/snap1 + +# Punch a hole in the last 16K of the last file extent item of the first leaf, +# which starts at file offset 12845056, so 12845056 + 64K - 16K = 12894208. +# This does not cause any change in the second leaf of the fs tree, so it will +# be shared between the snapshots. +$XFS_IO_PROG -c "fpunch 12894208 16K" $SCRATCH_MNT/foo + +_btrfs subvolume snapshot -r $SCRATCH_MNT $SCRATCH_MNT/snap2 + +echo "File digest in the original fs: $(_md5_checksum $SCRATCH_MNT/snap2/foo)" + +_btrfs send -f $first_stream $SCRATCH_MNT/snap1 +_btrfs send -f $second_stream -p $SCRATCH_MNT/snap1 $SCRATCH_MNT/snap2 + +# Create a new fs and apply both send streams. +_scratch_unmount +_scratch_mkfs >> $seqres.full 2>&1 || _fail "second mkfs failed" +_scratch_mount + +_btrfs receive -f $first_stream $SCRATCH_MNT +_btrfs receive -f $second_stream $SCRATCH_MNT + +echo "File digest in the new fs: $(_md5_checksum $SCRATCH_MNT/snap2/foo)" + +# Check the region we punched a hole is full of zeroes. +echo "Hole data:" +od -A d -t x1 -j 12894208 -N $((16 * 1024)) $SCRATCH_MNT/snap2/foo + +# success, all done +_exit 0 diff --git a/tests/btrfs/362.out b/tests/btrfs/362.out new file mode 100644 index 00000000..789abb53 --- /dev/null +++ b/tests/btrfs/362.out @@ -0,0 +1,7 @@ +QA output created by 362 +File digest in the original fs: a5a06694d9f7fc3245afb2f391636e44 +File digest in the new fs: a5a06694d9f7fc3245afb2f391636e44 +Hole data: +12894208 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +* +12910592 -- 2.53.0 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] btrfs: test an incremental send scenario with hole punching 2026-10-21 20:17 [PATCH] btrfs: test an incremental send scenario with hole punching fdmanana @ 2026-11-12 17:12 ` Johannes Thumshirn 2026-11-14 15:05 ` Zorro Lang 1 sibling, 0 replies; 5+ messages in thread From: Johannes Thumshirn @ 2026-11-12 17:12 UTC (permalink / raw) To: fdmanana; +Cc: fstests, linux-btrfs, Filipe Manana Looks good to me, Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] btrfs: test an incremental send scenario with hole punching 2026-10-21 20:17 [PATCH] btrfs: test an incremental send scenario with hole punching fdmanana 2026-11-12 17:12 ` Johannes Thumshirn @ 2026-11-14 15:05 ` Zorro Lang 2026-11-14 16:51 ` Filipe Manana 1 sibling, 1 reply; 5+ messages in thread From: Zorro Lang @ 2026-11-14 15:05 UTC (permalink / raw) To: fdmanana; +Cc: fstests, linux-btrfs, Filipe Manana On Wed, Oct 21, 2026 at 09:17:25PM +0100, fdmanana@kernel.org wrote: > From: Filipe Manana <fdmanana@suse.com> > > Test an incremental send scenario where we punched a hole into a tail > section of a file extent item that is the last item in a leaf and the > next leaf in the subvolume tree was not changed (remains shared between > the parent and send snapshots). > > This currently fails and is fixed by the following kernel patch: > > btrfs: send: fix missing hole punching during incremental send > > Signed-off-by: Filipe Manana <fdmanana@suse.com> > --- > tests/btrfs/362 | 84 +++++++++++++++++++++++++++++++++++++++++++++ > tests/btrfs/362.out | 7 ++++ > 2 files changed, 91 insertions(+) > create mode 100755 tests/btrfs/362 > create mode 100644 tests/btrfs/362.out > > diff --git a/tests/btrfs/362 b/tests/btrfs/362 > new file mode 100755 > index 00000000..aca56540 > --- /dev/null > +++ b/tests/btrfs/362 > @@ -0,0 +1,84 @@ > +#! /bin/bash > +# SPDX-License-Identifier: GPL-2.0 > +# Copyright (c) 2026 SUSE S.A. All Rights Reserved. > +# > +# FS QA Test 362 > +# > +# Test an incremental send scenario where we punched a hole into a tail section > +# of a file extent item that is the last item in a leaf and the next leaf in the > +# subvolume tree was not changed (remains shared between the parent and send > +# snapshots). > +# > +. ./common/preamble > +_begin_fstest auto quick send > + > +_cleanup() > +{ > + cd / > + rm -fr $tmp.* > + rm -fr $send_files_dir > +} > + > +. ./common/filter > + > +_require_test > +_require_scratch > +_require_btrfs_support_sectorsize 4096 > +_require_xfs_io_command "fpunch" > + > +_fixed_by_kernel_commit xxxxxxxxxx \ > + "btrfs: send: fix missing hole punching during incremental send" > + > +send_files_dir=$TEST_DIR/btrfs-test-$seq > + > +rm -fr $send_files_dir > +mkdir $send_files_dir > + > +first_stream="$send_files_dir/1.send" > +second_stream="$send_files_dir/2.send" > + > +# We need a very specific leaf layout where we punch a hole in the last file > +# extent item of a leaf and the next leaf was not modified in the send snapshot, > +# so we set a fixed size of 16K. > +_scratch_mkfs -n 16K >> $seqres.full 2>&1 || _fail "first mkfs failed" > +_scratch_mount > + > +touch $SCRATCH_MNT/foo > +# 205 extents of 64K each with a 64K hole between them. > +for ((i = 0; i < 410; i += 2)); do > + offset=$((i * 64 * 1024)) > + $XFS_IO_PROG -c "pwrite -b 64K -S 0xab $offset 64K" \ > + $SCRATCH_MNT/foo > /dev/null > +done > + > +_btrfs subvolume snapshot -r $SCRATCH_MNT $SCRATCH_MNT/snap1 > + > +# Punch a hole in the last 16K of the last file extent item of the first leaf, > +# which starts at file offset 12845056, so 12845056 + 64K - 16K = 12894208. > +# This does not cause any change in the second leaf of the fs tree, so it will > +# be shared between the snapshots. > +$XFS_IO_PROG -c "fpunch 12894208 16K" $SCRATCH_MNT/foo > + > +_btrfs subvolume snapshot -r $SCRATCH_MNT $SCRATCH_MNT/snap2 > + > +echo "File digest in the original fs: $(_md5_checksum $SCRATCH_MNT/snap2/foo)" > + > +_btrfs send -f $first_stream $SCRATCH_MNT/snap1 > +_btrfs send -f $second_stream -p $SCRATCH_MNT/snap1 $SCRATCH_MNT/snap2 > + > +# Create a new fs and apply both send streams. > +_scratch_unmount > +_scratch_mkfs >> $seqres.full 2>&1 || _fail "second mkfs failed" > +_scratch_mount > + > +_btrfs receive -f $first_stream $SCRATCH_MNT > +_btrfs receive -f $second_stream $SCRATCH_MNT > + > +echo "File digest in the new fs: $(_md5_checksum $SCRATCH_MNT/snap2/foo)" > + > +# Check the region we punched a hole is full of zeroes. > +echo "Hole data:" > +od -A d -t x1 -j 12894208 -N $((16 * 1024)) $SCRATCH_MNT/snap2/foo Can this be replaced with common helper: _hexdump ? Thanks, Zorro > + > +# success, all done > +_exit 0 > diff --git a/tests/btrfs/362.out b/tests/btrfs/362.out > new file mode 100644 > index 00000000..789abb53 > --- /dev/null > +++ b/tests/btrfs/362.out > @@ -0,0 +1,7 @@ > +QA output created by 362 > +File digest in the original fs: a5a06694d9f7fc3245afb2f391636e44 > +File digest in the new fs: a5a06694d9f7fc3245afb2f391636e44 > +Hole data: > +12894208 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > +* > +12910592 > -- > 2.53.0 > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] btrfs: test an incremental send scenario with hole punching 2026-11-14 15:05 ` Zorro Lang @ 2026-11-14 16:51 ` Filipe Manana 2026-11-14 21:21 ` Zorro Lang 0 siblings, 1 reply; 5+ messages in thread From: Filipe Manana @ 2026-11-14 16:51 UTC (permalink / raw) To: fdmanana, fstests, linux-btrfs, Filipe Manana On Sat, Nov 14, 2026 at 3:05 PM Zorro Lang <zlang@kernel.org> wrote: > > On Wed, Oct 21, 2026 at 09:17:25PM +0100, fdmanana@kernel.org wrote: > > From: Filipe Manana <fdmanana@suse.com> > > > > Test an incremental send scenario where we punched a hole into a tail > > section of a file extent item that is the last item in a leaf and the > > next leaf in the subvolume tree was not changed (remains shared between > > the parent and send snapshots). > > > > This currently fails and is fixed by the following kernel patch: > > > > btrfs: send: fix missing hole punching during incremental send > > > > Signed-off-by: Filipe Manana <fdmanana@suse.com> > > --- > > tests/btrfs/362 | 84 +++++++++++++++++++++++++++++++++++++++++++++ > > tests/btrfs/362.out | 7 ++++ > > 2 files changed, 91 insertions(+) > > create mode 100755 tests/btrfs/362 > > create mode 100644 tests/btrfs/362.out > > > > diff --git a/tests/btrfs/362 b/tests/btrfs/362 > > new file mode 100755 > > index 00000000..aca56540 > > --- /dev/null > > +++ b/tests/btrfs/362 > > @@ -0,0 +1,84 @@ > > +#! /bin/bash > > +# SPDX-License-Identifier: GPL-2.0 > > +# Copyright (c) 2026 SUSE S.A. All Rights Reserved. > > +# > > +# FS QA Test 362 > > +# > > +# Test an incremental send scenario where we punched a hole into a tail section > > +# of a file extent item that is the last item in a leaf and the next leaf in the > > +# subvolume tree was not changed (remains shared between the parent and send > > +# snapshots). > > +# > > +. ./common/preamble > > +_begin_fstest auto quick send > > + > > +_cleanup() > > +{ > > + cd / > > + rm -fr $tmp.* > > + rm -fr $send_files_dir > > +} > > + > > +. ./common/filter > > + > > +_require_test > > +_require_scratch > > +_require_btrfs_support_sectorsize 4096 > > +_require_xfs_io_command "fpunch" > > + > > +_fixed_by_kernel_commit xxxxxxxxxx \ > > + "btrfs: send: fix missing hole punching during incremental send" > > + > > +send_files_dir=$TEST_DIR/btrfs-test-$seq > > + > > +rm -fr $send_files_dir > > +mkdir $send_files_dir > > + > > +first_stream="$send_files_dir/1.send" > > +second_stream="$send_files_dir/2.send" > > + > > +# We need a very specific leaf layout where we punch a hole in the last file > > +# extent item of a leaf and the next leaf was not modified in the send snapshot, > > +# so we set a fixed size of 16K. > > +_scratch_mkfs -n 16K >> $seqres.full 2>&1 || _fail "first mkfs failed" > > +_scratch_mount > > + > > +touch $SCRATCH_MNT/foo > > +# 205 extents of 64K each with a 64K hole between them. > > +for ((i = 0; i < 410; i += 2)); do > > + offset=$((i * 64 * 1024)) > > + $XFS_IO_PROG -c "pwrite -b 64K -S 0xab $offset 64K" \ > > + $SCRATCH_MNT/foo > /dev/null > > +done > > + > > +_btrfs subvolume snapshot -r $SCRATCH_MNT $SCRATCH_MNT/snap1 > > + > > +# Punch a hole in the last 16K of the last file extent item of the first leaf, > > +# which starts at file offset 12845056, so 12845056 + 64K - 16K = 12894208. > > +# This does not cause any change in the second leaf of the fs tree, so it will > > +# be shared between the snapshots. > > +$XFS_IO_PROG -c "fpunch 12894208 16K" $SCRATCH_MNT/foo > > + > > +_btrfs subvolume snapshot -r $SCRATCH_MNT $SCRATCH_MNT/snap2 > > + > > +echo "File digest in the original fs: $(_md5_checksum $SCRATCH_MNT/snap2/foo)" > > + > > +_btrfs send -f $first_stream $SCRATCH_MNT/snap1 > > +_btrfs send -f $second_stream -p $SCRATCH_MNT/snap1 $SCRATCH_MNT/snap2 > > + > > +# Create a new fs and apply both send streams. > > +_scratch_unmount > > +_scratch_mkfs >> $seqres.full 2>&1 || _fail "second mkfs failed" > > +_scratch_mount > > + > > +_btrfs receive -f $first_stream $SCRATCH_MNT > > +_btrfs receive -f $second_stream $SCRATCH_MNT > > + > > +echo "File digest in the new fs: $(_md5_checksum $SCRATCH_MNT/snap2/foo)" > > + > > +# Check the region we punched a hole is full of zeroes. > > +echo "Hole data:" > > +od -A d -t x1 -j 12894208 -N $((16 * 1024)) $SCRATCH_MNT/snap2/foo > > > Can this be replaced with common helper: _hexdump ? I don't have a strong objection to that, but honestly I prefer it as it is because it prints the addresses in decimal format, which is more human readable and directly matches the value passed to the hole punching operation above, making it easier to read. Do you want to make the change yourself, or should I send a new version just for that? > > Thanks, > Zorro > > > + > > +# success, all done > > +_exit 0 > > diff --git a/tests/btrfs/362.out b/tests/btrfs/362.out > > new file mode 100644 > > index 00000000..789abb53 > > --- /dev/null > > +++ b/tests/btrfs/362.out > > @@ -0,0 +1,7 @@ > > +QA output created by 362 > > +File digest in the original fs: a5a06694d9f7fc3245afb2f391636e44 > > +File digest in the new fs: a5a06694d9f7fc3245afb2f391636e44 > > +Hole data: > > +12894208 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > +* > > +12910592 > > -- > > 2.53.0 > > > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] btrfs: test an incremental send scenario with hole punching 2026-11-14 16:51 ` Filipe Manana @ 2026-11-14 21:21 ` Zorro Lang 0 siblings, 0 replies; 5+ messages in thread From: Zorro Lang @ 2026-11-14 21:21 UTC (permalink / raw) To: Filipe Manana; +Cc: fstests, linux-btrfs, Filipe Manana On Sat, Nov 14, 2026 at 04:51:27PM +0000, Filipe Manana wrote: > On Sat, Nov 14, 2026 at 3:05 PM Zorro Lang <zlang@kernel.org> wrote: > > > > On Wed, Oct 21, 2026 at 09:17:25PM +0100, fdmanana@kernel.org wrote: > > > From: Filipe Manana <fdmanana@suse.com> > > > > > > Test an incremental send scenario where we punched a hole into a tail > > > section of a file extent item that is the last item in a leaf and the > > > next leaf in the subvolume tree was not changed (remains shared between > > > the parent and send snapshots). > > > > > > This currently fails and is fixed by the following kernel patch: > > > > > > btrfs: send: fix missing hole punching during incremental send > > > > > > Signed-off-by: Filipe Manana <fdmanana@suse.com> > > > --- > > > tests/btrfs/362 | 84 +++++++++++++++++++++++++++++++++++++++++++++ > > > tests/btrfs/362.out | 7 ++++ > > > 2 files changed, 91 insertions(+) > > > create mode 100755 tests/btrfs/362 > > > create mode 100644 tests/btrfs/362.out > > > > > > diff --git a/tests/btrfs/362 b/tests/btrfs/362 > > > new file mode 100755 > > > index 00000000..aca56540 > > > --- /dev/null > > > +++ b/tests/btrfs/362 > > > @@ -0,0 +1,84 @@ > > > +#! /bin/bash > > > +# SPDX-License-Identifier: GPL-2.0 > > > +# Copyright (c) 2026 SUSE S.A. All Rights Reserved. > > > +# > > > +# FS QA Test 362 > > > +# > > > +# Test an incremental send scenario where we punched a hole into a tail section > > > +# of a file extent item that is the last item in a leaf and the next leaf in the > > > +# subvolume tree was not changed (remains shared between the parent and send > > > +# snapshots). > > > +# > > > +. ./common/preamble > > > +_begin_fstest auto quick send > > > + > > > +_cleanup() > > > +{ > > > + cd / > > > + rm -fr $tmp.* > > > + rm -fr $send_files_dir > > > +} > > > + > > > +. ./common/filter > > > + > > > +_require_test > > > +_require_scratch > > > +_require_btrfs_support_sectorsize 4096 > > > +_require_xfs_io_command "fpunch" > > > + > > > +_fixed_by_kernel_commit xxxxxxxxxx \ > > > + "btrfs: send: fix missing hole punching during incremental send" > > > + > > > +send_files_dir=$TEST_DIR/btrfs-test-$seq > > > + > > > +rm -fr $send_files_dir > > > +mkdir $send_files_dir > > > + > > > +first_stream="$send_files_dir/1.send" > > > +second_stream="$send_files_dir/2.send" > > > + > > > +# We need a very specific leaf layout where we punch a hole in the last file > > > +# extent item of a leaf and the next leaf was not modified in the send snapshot, > > > +# so we set a fixed size of 16K. > > > +_scratch_mkfs -n 16K >> $seqres.full 2>&1 || _fail "first mkfs failed" > > > +_scratch_mount > > > + > > > +touch $SCRATCH_MNT/foo > > > +# 205 extents of 64K each with a 64K hole between them. > > > +for ((i = 0; i < 410; i += 2)); do > > > + offset=$((i * 64 * 1024)) > > > + $XFS_IO_PROG -c "pwrite -b 64K -S 0xab $offset 64K" \ > > > + $SCRATCH_MNT/foo > /dev/null > > > +done > > > + > > > +_btrfs subvolume snapshot -r $SCRATCH_MNT $SCRATCH_MNT/snap1 > > > + > > > +# Punch a hole in the last 16K of the last file extent item of the first leaf, > > > +# which starts at file offset 12845056, so 12845056 + 64K - 16K = 12894208. > > > +# This does not cause any change in the second leaf of the fs tree, so it will > > > +# be shared between the snapshots. > > > +$XFS_IO_PROG -c "fpunch 12894208 16K" $SCRATCH_MNT/foo > > > + > > > +_btrfs subvolume snapshot -r $SCRATCH_MNT $SCRATCH_MNT/snap2 > > > + > > > +echo "File digest in the original fs: $(_md5_checksum $SCRATCH_MNT/snap2/foo)" > > > + > > > +_btrfs send -f $first_stream $SCRATCH_MNT/snap1 > > > +_btrfs send -f $second_stream -p $SCRATCH_MNT/snap1 $SCRATCH_MNT/snap2 > > > + > > > +# Create a new fs and apply both send streams. > > > +_scratch_unmount > > > +_scratch_mkfs >> $seqres.full 2>&1 || _fail "second mkfs failed" > > > +_scratch_mount > > > + > > > +_btrfs receive -f $first_stream $SCRATCH_MNT > > > +_btrfs receive -f $second_stream $SCRATCH_MNT > > > + > > > +echo "File digest in the new fs: $(_md5_checksum $SCRATCH_MNT/snap2/foo)" > > > + > > > +# Check the region we punched a hole is full of zeroes. > > > +echo "Hole data:" > > > +od -A d -t x1 -j 12894208 -N $((16 * 1024)) $SCRATCH_MNT/snap2/foo > > > > > > Can this be replaced with common helper: _hexdump ? > > I don't have a strong objection to that, but honestly I prefer it as > it is because it prints the addresses in decimal format, which is more > human readable and directly matches the value passed to the hole > punching operation above, making it easier to read. > > Do you want to make the change yourself, or should I send a new > version just for that? If I were to change it, I'd have to merge the kernel patch above, rebuild and install the kernel, run the tests, and then update the .out file. Never mind, just using od works fine too, since the _hexdump helper was originally introduced to replace the widespread use of the hexdump command anyway. Anyway, no need to send a new version. If I find some time, I'll make the change myself, or merging it directly :) Thanks, Zorro > > > > > Thanks, > > Zorro > > > > > + > > > +# success, all done > > > +_exit 0 > > > diff --git a/tests/btrfs/362.out b/tests/btrfs/362.out > > > new file mode 100644 > > > index 00000000..789abb53 > > > --- /dev/null > > > +++ b/tests/btrfs/362.out > > > @@ -0,0 +1,7 @@ > > > +QA output created by 362 > > > +File digest in the original fs: a5a06694d9f7fc3245afb2f391636e44 > > > +File digest in the new fs: a5a06694d9f7fc3245afb2f391636e44 > > > +Hole data: > > > +12894208 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > +* > > > +12910592 > > > -- > > > 2.53.0 > > > > > > > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-11-14 21:21 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-10-21 20:17 [PATCH] btrfs: test an incremental send scenario with hole punching fdmanana 2026-11-12 17:12 ` Johannes Thumshirn 2026-11-14 15:05 ` Zorro Lang 2026-11-14 16:51 ` Filipe Manana 2026-11-14 21:21 ` Zorro Lang
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.