* [git pull] vfs pile 2
@ 2009-12-17 16:24 Al Viro
2009-12-17 16:39 ` Linus Torvalds
0 siblings, 1 reply; 11+ messages in thread
From: Al Viro @ 2009-12-17 16:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
Misc bits and pieces, cleaning the table for scaling stuff...
Please, pull from
git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git/ master
in a few minutes (or directly from hera)
Al Viro (1):
dio: fix use-after-free
Christoph Hellwig (3):
fix up O_SYNC comments
fold do_sync_file_range into sys_sync_file_range
kill I_LOCK
Erez Zadok (2):
fsstack/ecryptfs: remove unused get_nlinks param to fsstack_copy_attr_all
VFS/fsstack: handle 32-bit smp + preempt + large files in fsstack_copy_inode_size
Jeff Layton (1):
vfs: remove extraneous NULL d_inode check from do_filp_open
Nick Piggin (2):
fs: anon_inodes implement dname
fs: no games with DCACHE_UNHASHED
Diffstat:
arch/alpha/include/asm/fcntl.h | 2 +-
arch/mips/include/asm/fcntl.h | 2 +-
arch/sparc/include/asm/fcntl.h | 2 +-
fs/anon_inodes.c | 17 ++++------
fs/direct-io.c | 2 +-
fs/ecryptfs/dentry.c | 2 +-
fs/ecryptfs/inode.c | 6 ++--
fs/ecryptfs/main.c | 2 +-
fs/gfs2/inode.c | 2 +-
fs/inode.c | 26 +++++++-------
fs/jfs/jfs_txnmgr.c | 2 +-
fs/namei.c | 2 +-
fs/ntfs/inode.c | 6 ++--
fs/pipe.c | 18 ----------
fs/stack.c | 71 ++++++++++++++++++++++++++++++---------
fs/sync.c | 59 +++++++++++++--------------------
fs/ubifs/file.c | 2 +-
fs/xfs/linux-2.6/xfs_iops.c | 2 +-
fs/xfs/xfs_iget.c | 4 +-
include/asm-generic/fcntl.h | 2 +-
include/linux/fs.h | 40 +++++++++-------------
include/linux/fs_stack.h | 6 +--
include/linux/writeback.h | 3 +-
net/socket.c | 19 -----------
24 files changed, 136 insertions(+), 163 deletions(-)
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [git pull] vfs pile 2
2009-12-17 16:24 [git pull] vfs pile 2 Al Viro
@ 2009-12-17 16:39 ` Linus Torvalds
2009-12-17 18:03 ` Al Viro
0 siblings, 1 reply; 11+ messages in thread
From: Linus Torvalds @ 2009-12-17 16:39 UTC (permalink / raw)
To: Al Viro; +Cc: linux-kernel
On Thu, 17 Dec 2009, Al Viro wrote:
>
> Misc bits and pieces, cleaning the table for scaling stuff...
> Please, pull from
> git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git/ master
> in a few minutes (or directly from hera)
Btw, would you mind cleaning that repo up?
It has a few very annoying things, the first and foremost of which is that
HEAD points to some crazy branch (new-truncate).
So when you do "git pull" without mentioning the branch (which is the
normal behavior) and would expect to get your default thing (which was
also what you asked me to pull in your original pull request), you instead
get some totally inexplicable old random crud.
That's really unexpected for a bare repository. I spent some time looking
at the odd conflicts the other day when I pulled originally.
I suspect you just did a "scp -rp" or something to initially set it up,
which is why it contains some random branch - that just happened to be
your active branch at the time you did that setup.
(It also has FETCH_HEAD, index, COMMIT_EDITMSG etc - all things that don't
make sense in a bare repository)
Linus
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [git pull] vfs pile 2
2009-12-17 16:39 ` Linus Torvalds
@ 2009-12-17 18:03 ` Al Viro
2009-12-17 18:16 ` Linus Torvalds
0 siblings, 1 reply; 11+ messages in thread
From: Al Viro @ 2009-12-17 18:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
On Thu, Dec 17, 2009 at 08:39:14AM -0800, Linus Torvalds wrote:
>
>
> On Thu, 17 Dec 2009, Al Viro wrote:
> >
> > Misc bits and pieces, cleaning the table for scaling stuff...
> > Please, pull from
> > git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git/ master
> > in a few minutes (or directly from hera)
>
> Btw, would you mind cleaning that repo up?
Sure.
> That's really unexpected for a bare repository. I spent some time looking
> at the odd conflicts the other day when I pulled originally.
>
> I suspect you just did a "scp -rp" or something to initially set it up,
> which is why it contains some random branch - that just happened to be
> your active branch at the time you did that setup.
IIRC, it was _way_ back and done as git clone -l -s <your tree> vfs-2.6
followed by mv vfs-2.6/.git /pub/scm/...../vfs-2.6.git. So it probably
_isn't_ a proper bare repository in the first place.
OK... I've edited config a bit, set HEAD to ref: refs/heads/master and
tried to clean the things up. What I still don't understand is why the
hell does it have an apparently unkillable dangling commit that seems
to be yours, despite having alternates pointing to your tree. *And*
a bunch of loose objects sitting around and impossible to get rid of...
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [git pull] vfs pile 2
2009-12-17 18:03 ` Al Viro
@ 2009-12-17 18:16 ` Linus Torvalds
2009-12-17 18:39 ` Al Viro
0 siblings, 1 reply; 11+ messages in thread
From: Linus Torvalds @ 2009-12-17 18:16 UTC (permalink / raw)
To: Al Viro; +Cc: linux-kernel
On Thu, 17 Dec 2009, Al Viro wrote:
>
> OK... I've edited config a bit, set HEAD to ref: refs/heads/master and
> tried to clean the things up. What I still don't understand is why the
> hell does it have an apparently unkillable dangling commit that seems
> to be yours, despite having alternates pointing to your tree. *And*
> a bunch of loose objects sitting around and impossible to get rid of...
Git is _very_ nervous about getting rid of old objects, because even if
they aren't reachable, you might recover them with "git fsck" etc. By
default there's something like a 2-month (or maybe just two weeks, I'm too
lazy to check) expiration logic for objects that are loose and
unreachable.
You can force git to get rid of those kinds of objects using
git prune --expire=now
or similar.
[ Btw, things that _look_ unreachable may also be reachable through the
reflog, which is not normally something you'd have in a bare repository
anyway, but since you created the bare repo by copying/moving a non-bare
one, you may well have reflog entries.
Doing
git reflog expire --all --expire=now
should get rid of them, but you could also decide to just do it all the
brute-force way with just "rm -rf logs" ]
Linus
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [git pull] vfs pile 2
2009-12-17 18:16 ` Linus Torvalds
@ 2009-12-17 18:39 ` Al Viro
2009-12-17 21:22 ` Linus Torvalds
0 siblings, 1 reply; 11+ messages in thread
From: Al Viro @ 2009-12-17 18:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
On Thu, Dec 17, 2009 at 10:16:08AM -0800, Linus Torvalds wrote:
> You can force git to get rid of those kinds of objects using
>
> git prune --expire=now
>
> or similar.
>
> [ Btw, things that _look_ unreachable may also be reachable through the
> reflog, which is not normally something you'd have in a bare repository
> anyway, but since you created the bare repo by copying/moving a non-bare
> one, you may well have reflog entries.
>
> Doing
>
> git reflog expire --all --expire=now
>
> should get rid of them, but you could also decide to just do it all the
> brute-force way with just "rm -rf logs" ]
reflog had been pruned already; still no effect. Moreover, after looking
through the loose objects, I've found several commits that are definitely
reachable from master and now from your tree as well. E.g.
objects/ea/ff8079d4f1016a12e34ab323737314f24127dd
is one of those - it's a commit and it's both in mainline *and* happens
to be tip of master. No questions about being unreachable and AFAICS
no reasons whatsoever to leave it as a loose object...
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [git pull] vfs pile 2
2009-12-17 18:39 ` Al Viro
@ 2009-12-17 21:22 ` Linus Torvalds
2009-12-17 21:43 ` Al Viro
0 siblings, 1 reply; 11+ messages in thread
From: Linus Torvalds @ 2009-12-17 21:22 UTC (permalink / raw)
To: Al Viro; +Cc: linux-kernel
On Thu, 17 Dec 2009, Al Viro wrote:
>
> reflog had been pruned already; still no effect. Moreover, after looking
> through the loose objects, I've found several commits that are definitely
> reachable from master and now from your tree as well. E.g.
> objects/ea/ff8079d4f1016a12e34ab323737314f24127dd
> is one of those - it's a commit and it's both in mainline *and* happens
> to be tip of master. No questions about being unreachable and AFAICS
> no reasons whatsoever to leave it as a loose object...
If you want a maximal pack, use "git repack -Adl"
The default gc thing will stop when it hits stuff that has been packed
already, which can leave _older_ unpacked objects unpacked. And since my
own repo isn't always fully packed, and git will only remove local objects
if they are available as _packed_ objects in the reference tree (ie my
repo), you'll end up with that kind of situation.
I usually repack my tree a couple of times per release, no more often, so
you'll seldom see _perfect_ packing.
Linus
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [git pull] vfs pile 2
2009-12-17 21:22 ` Linus Torvalds
@ 2009-12-17 21:43 ` Al Viro
2009-12-17 21:58 ` Linus Torvalds
0 siblings, 1 reply; 11+ messages in thread
From: Al Viro @ 2009-12-17 21:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
On Thu, Dec 17, 2009 at 01:22:12PM -0800, Linus Torvalds wrote:
>
>
> On Thu, 17 Dec 2009, Al Viro wrote:
> >
> > reflog had been pruned already; still no effect. Moreover, after looking
> > through the loose objects, I've found several commits that are definitely
> > reachable from master and now from your tree as well. E.g.
> > objects/ea/ff8079d4f1016a12e34ab323737314f24127dd
> > is one of those - it's a commit and it's both in mainline *and* happens
> > to be tip of master. No questions about being unreachable and AFAICS
> > no reasons whatsoever to leave it as a loose object...
>
> If you want a maximal pack, use "git repack -Adl"
Still leaves the same bunch.
> The default gc thing will stop when it hits stuff that has been packed
> already, which can leave _older_ unpacked objects unpacked. And since my
> own repo isn't always fully packed, and git will only remove local objects
> if they are available as _packed_ objects in the reference tree (ie my
> repo), you'll end up with that kind of situation.
Yeah, but why aren't they put into local pack? They _are_ new and they
definitely are referenced. The newest in the repository, as the matter
of fact.
Odd...
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [git pull] vfs pile 2
2009-12-17 21:43 ` Al Viro
@ 2009-12-17 21:58 ` Linus Torvalds
0 siblings, 0 replies; 11+ messages in thread
From: Linus Torvalds @ 2009-12-17 21:58 UTC (permalink / raw)
To: Al Viro; +Cc: Linux Kernel Mailing List
On Thu, 17 Dec 2009, Al Viro wrote:
>
> Yeah, but why aren't they put into local pack? They _are_ new and they
> definitely are referenced. The newest in the repository, as the matter
> of fact.
>
> Odd...
Hmm. It seems to be the same objects that are unpacked in my repo. What
happens is probably that git doesn't want to pack them, because they are
available in the alternates, but then also doesn't want to prune them,
because they aren't available in a _pack_ in the alternate.
That does look like something we migth decide to want to change in git.
Maybe.
But I repacked my repo, just so that you can get your "no loose objects"
situation you want ;)
Linus
^ permalink raw reply [flat|nested] 11+ messages in thread
* [git pull] vfs, pile 2
@ 2010-10-29 13:25 Al Viro
0 siblings, 0 replies; 11+ messages in thread
From: Al Viro @ 2010-10-29 13:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-fsdevel
Misc fixes + easy parts of ->mount() conversion (everything
sans ->mnt_devname work in NFS). That's not all; I still hope to get
icache stuff done, for one thing. Please, pull from
git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git/ #for-linus
Shortlog:
Al Viro (29):
a couple of open-coded ihold() introduced by nfs merge
fix open/umount race
beginning of transtion: ->mount()
new helper: mount_bdev()
convert get_sb_mtd() users to ->mount()
convert get_sb_single() users
convert get_sb_nodev() users
convert get_sb_pseudo() users
convert ubifs
convert v9fs
logfs get_sb massage, part 1
logfs get_sb, part 2
logfs get_sb, part 3
logfs: fix a leak in get_sb
switch logfs to ->mount()
convert nilfs
convert cifs
setting ->proc_mnt doesn't belong in proc_get_sb()
switch procfs to ->mount()
switch get_sb_ns() users
convert cgroup and cpuset
convert sysfs
convert ecryptfs
convert afs
convert gfs2
convert ceph
convert btrfs
convert simple cases of nfs-related ->get_sb() to ->mount()
braino in internal.h
Diffstat:
arch/ia64/kernel/perfmon.c | 9 +--
arch/powerpc/platforms/cell/spufs/inode.c | 10 ++--
arch/s390/hypfs/inode.c | 8 +-
drivers/base/devtmpfs.c | 18 +++---
drivers/infiniband/hw/ipath/ipath_fs.c | 14 ++--
drivers/infiniband/hw/qib/qib_fs.c | 14 ++--
drivers/isdn/capi/capifs.c | 8 +-
drivers/misc/ibmasm/ibmasmfs.c | 9 +--
drivers/mtd/mtdchar.c | 10 +--
drivers/mtd/mtdsuper.c | 54 ++++++--------
drivers/oprofile/oprofilefs.c | 8 +-
drivers/staging/autofs/init.c | 8 +-
drivers/staging/pohmelfs/inode.c | 9 +--
drivers/staging/smbfs/inode.c | 8 +-
drivers/usb/core/inode.c | 8 +-
drivers/usb/gadget/f_fs.c | 14 ++--
drivers/usb/gadget/inode.c | 10 ++--
drivers/xen/xenfs/super.c | 8 +-
fs/9p/vfs_super.c | 22 +++---
fs/adfs/super.c | 9 +--
fs/affs/super.c | 9 +--
fs/afs/super.c | 19 ++---
fs/anon_inodes.c | 10 +--
fs/autofs4/init.c | 8 +-
fs/befs/linuxvfs.c | 11 ++--
fs/bfs/inode.c | 8 +-
fs/binfmt_misc.c | 8 +-
fs/block_dev.c | 8 +-
fs/btrfs/super.c | 15 ++---
fs/ceph/super.c | 50 +++++++------
fs/cifs/cifsfs.c | 15 ++--
fs/coda/inode.c | 8 +-
fs/configfs/mount.c | 8 +-
fs/cramfs/inode.c | 9 +--
fs/debugfs/inode.c | 8 +-
fs/devpts/inode.c | 32 ++++-----
fs/ecryptfs/main.c | 12 ++--
fs/efs/super.c | 8 +-
fs/exofs/super.c | 10 ++--
fs/ext2/super.c | 8 +-
fs/ext3/super.c | 8 +-
fs/ext4/super.c | 16 ++--
fs/fat/namei_msdos.c | 9 +--
fs/fat/namei_vfat.c | 9 +--
fs/freevxfs/vxfs_super.c | 9 +--
fs/fuse/control.c | 10 +--
fs/fuse/inode.c | 17 ++---
fs/gfs2/ops_fstype.c | 51 ++++++--------
fs/hfs/super.c | 9 +--
fs/hfsplus/super.c | 10 +--
fs/hostfs/hostfs_kern.c | 8 +-
fs/hpfs/super.c | 9 +--
fs/hppfs/hppfs.c | 8 +-
fs/hugetlbfs/inode.c | 8 +-
fs/internal.h | 2 +-
fs/isofs/inode.c | 9 +--
fs/jffs2/super.c | 9 +--
fs/jfs/super.c | 9 +--
fs/libfs.c | 14 ++--
fs/logfs/dev_bdev.c | 15 +++--
fs/logfs/dev_mtd.c | 18 +++---
fs/logfs/logfs.h | 22 +++---
fs/logfs/super.c | 77 ++++++++++----------
fs/minix/inode.c | 9 +--
fs/namei.c | 2 +
fs/ncpfs/inode.c | 8 +-
fs/nfs/super.c | 96 ++++++++++++-------------
fs/nfs/unlink.c | 4 +-
fs/nfsd/nfsctl.c | 8 +-
fs/nilfs2/super.c | 16 ++---
fs/ntfs/super.c | 9 +--
fs/ocfs2/dlmfs/dlmfs.c | 8 +-
fs/ocfs2/super.c | 11 +--
fs/omfs/inode.c | 9 +--
fs/open.c | 6 +-
fs/openpromfs/inode.c | 8 +-
fs/pipe.c | 9 +--
fs/proc/root.c | 16 ++--
fs/qnx4/inode.c | 9 +--
fs/ramfs/inode.c | 17 ++---
fs/reiserfs/super.c | 9 +--
fs/romfs/super.c | 17 ++---
fs/squashfs/super.c | 10 +--
fs/super.c | 111 +++++++++++++++++++++--------
fs/sysfs/mount.c | 32 ++++-----
fs/sysv/super.c | 17 ++---
fs/ubifs/super.c | 13 ++--
fs/udf/super.c | 9 +--
fs/ufs/super.c | 8 +-
fs/xfs/linux-2.6/xfs_super.c | 12 ++--
include/linux/fs.h | 21 ++++--
include/linux/mtd/super.h | 5 +-
include/linux/ramfs.h | 4 +-
ipc/mqueue.c | 8 +-
kernel/cgroup.c | 11 ++--
kernel/cpuset.c | 13 ++--
mm/shmem.c | 10 ++--
net/socket.c | 10 +--
net/sunrpc/rpc_pipe.c | 18 +++---
security/inode.c | 8 +-
security/selinux/selinuxfs.c | 9 +--
security/smack/smackfs.c | 12 ++--
102 files changed, 731 insertions(+), 759 deletions(-)
^ permalink raw reply [flat|nested] 11+ messages in thread* [git pull] vfs pile 2
@ 2016-08-06 1:36 Al Viro
0 siblings, 0 replies; 11+ messages in thread
From: Al Viro @ 2016-08-06 1:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-fsdevel
Fairly self-contained bunch - surprising lot of places passes
struct qstr * as an argument when const struct qstr * would suffice;
it complicates analysis for no good reason. I'd prefer to feed that
separately from the assorted fixes (those are in #for-linus and with
somewhat trickier topology).
One trivial conflict in f2fs - arguments of f2fs_inode_by_name()
and f2fs_find_entry() are modified both here and in mainline. Mainline adds
struct page ** and this series turns struct qstr * to const struct qstr *.
Changes are independent, resolved in an obvious way.
The following changes since commit 92d21ac74a9e3c09b0b01c764e530657e4c85c49:
Linux 4.7-rc7 (2016-07-10 20:24:59 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.const-qstr
for you to fetch changes up to 19a6d89de2f10ee3b18c3b9fd6c7c2e249a30d71:
qstr: constify instances in adfs (2016-07-30 12:25:53 -0400)
----------------------------------------------------------------
Al Viro (15):
qstr: constify dentry_init_security
qstr: constify instances in logfs
qstr: constify instances in hfsplus
qstr: constify instances in hfs
qstr: constify instances in autofs4
qstr: constify instances in ocfs2
qstr: constify instances in nfs
qstr constify instances in fs/dcache.c
qstr: constify instances in fuse
qstr: constify instances in procfs
qstr: constify instances in vfat
qstr: constify instances in ext2
qstr: constify instances in f2fs
qstr: constify instances in lustre
qstr: constify instances in adfs
drivers/staging/lustre/lustre/llite/statahead.c | 4 ++--
fs/adfs/dir.c | 4 ++--
fs/autofs4/root.c | 8 ++++----
fs/autofs4/waitq.c | 4 ++--
fs/dcache.c | 4 ++--
fs/ext2/dir.c | 6 +++---
fs/ext2/ext2.h | 4 ++--
fs/f2fs/dir.c | 4 ++--
fs/f2fs/f2fs.h | 4 ++--
fs/fat/namei_vfat.c | 6 +++---
fs/fuse/dir.c | 4 ++--
fs/fuse/fuse_i.h | 2 +-
fs/fuse/inode.c | 8 ++------
fs/hfs/catalog.c | 12 ++++++------
fs/hfs/hfs_fs.h | 14 +++++++-------
fs/hfs/inode.c | 2 +-
fs/hfs/trans.c | 2 +-
fs/hfsplus/catalog.c | 12 ++++++------
fs/hfsplus/hfsplus_fs.h | 10 +++++-----
fs/logfs/dir.c | 4 ++--
fs/nfs/nfs3proc.c | 8 ++++----
fs/nfs/nfs4_fs.h | 5 +++--
fs/nfs/nfs4namespace.c | 4 ++--
fs/nfs/nfs4proc.c | 16 ++++++++--------
fs/nfs/proc.c | 8 ++++----
fs/nfs/unlink.c | 2 +-
fs/ocfs2/dlm/dlmdomain.c | 4 +---
fs/ocfs2/dlmfs/dlmfs.c | 4 ++--
fs/ocfs2/dlmfs/userdlm.c | 2 +-
fs/ocfs2/dlmfs/userdlm.h | 2 +-
fs/proc/proc_sysctl.c | 2 +-
include/linux/dcache.h | 2 +-
include/linux/lsm_hooks.h | 2 +-
include/linux/nfs_xdr.h | 8 ++++----
include/linux/security.h | 4 ++--
security/security.c | 2 +-
security/selinux/hooks.c | 2 +-
37 files changed, 95 insertions(+), 100 deletions(-)
^ permalink raw reply [flat|nested] 11+ messages in thread* [git pull] vfs, pile 2
@ 2018-06-04 1:02 Al Viro
0 siblings, 0 replies; 11+ messages in thread
From: Al Viro @ 2018-06-04 1:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-fsdevel, linux-kernel
More shrink_dcache_parent()-related stuff - killing the main
source of potentially contended calls of that on large subtrees.
The following changes since commit 4faa99965e027cc057c5145ce45fa772caa04e8d:
fix io_destroy()/aio_complete() race (2018-05-23 22:53:22 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.rmdir
for you to fetch changes up to 8767712f26d18ac4541e2d0d7be17c40a5911ce4:
rmdir(),rename(): do shrink_dcache_parent() only on success (2018-05-27 16:23:51 -0400)
----------------------------------------------------------------
Al Viro (1):
rmdir(),rename(): do shrink_dcache_parent() only on success
fs/namei.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2018-06-04 1:02 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-12-17 16:24 [git pull] vfs pile 2 Al Viro
2009-12-17 16:39 ` Linus Torvalds
2009-12-17 18:03 ` Al Viro
2009-12-17 18:16 ` Linus Torvalds
2009-12-17 18:39 ` Al Viro
2009-12-17 21:22 ` Linus Torvalds
2009-12-17 21:43 ` Al Viro
2009-12-17 21:58 ` Linus Torvalds
2010-10-29 13:25 [git pull] vfs, " Al Viro
2016-08-06 1:36 [git pull] vfs " Al Viro
2018-06-04 1:02 [git pull] vfs, " Al Viro
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).