More website updates

Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>

4 files changed, 67 insertions, 54 deletions

diff --git a/FAQ.mdwn b/FAQ.mdwn
index c45230b..26c504b 100644
--- a/FAQ.mdwn
+++ b/FAQ.mdwn
@@ -1,19 +1,16 @@
 Frequently Asked Questions
 
-
-## Does bcachefs support ACL/xattrs ?
-Yes it supports both ACL and xattrs.
-
-
 ## Do I have to reformat my bcache drive to use the new bcachefs ?
 
-To use the caching device (cdev) with the new bcachefs, you will need to reformat it.
-In principle this should not be a problem, as they can be removed from a backing device (bdev/bcache).
+To use the caching device (cdev) with the new bcachefs, you will need to
+reformat it. In principle this should not be a problem, as they can be removed
+from a backing device (bdev/bcache).
 
-If you wish to reuse the backing device (bdev/bcache), you can't this is nolonger an option.
+If you wish to reuse the backing device (bdev/bcache), you can't this is
+nolonger an option.
 
-If you wish to use bcachefs as a filesystem you will have to format the backing device (bdev/bcache) with
-the new filesystem.
+If you wish to use bcachefs as a filesystem you will have to format the
+backing device (bdev/bcache) with the new filesystem.
 
 ## Does bcachefs still have the bcache caching functionality of block devices ?
 
@@ -21,22 +18,20 @@ No.
 
 ## Where do I obtain statically linked bcachefs-tool (for use in initramfs) ?
 
-You can either compile them yourself from source,
-or refer to your distribution on how to obtain a statically linked set.
+You can either compile them yourself from source, or refer to your
+distribution on how to obtain a statically linked set.
+
+Statically linked programs have all the required dependencies compiled in. As
+such, they require no external libraries at runtime. This does however
+increase the size of the binary.
 
-About:
-Statically linked programs have all the required dependencies compiled in.
-As such, they require no external libraries at runtime.
-This does however increase the size of the binary.
+## What is liburcu ?
 
-##What is liburcu ?
 userspace RCU (read-copy-update) library
 [[http://lttng.org/urcu]]
 
-##I get the error "tools-util.c:16:19: fatal error: blkid.h: No such file or directory":
+## I get the error "tools-util.c:16:19: fatal error: blkid.h: No such file or directory":
+
 You might need to add
 	EXTRA_CFLAGS="-l/usr/include/blkid/"
 or where-ever your OS stores the blkid.h file.
-
-
-
diff --git a/Roadmap.mdwn b/Roadmap.mdwn
index 1e926e9..f814edf 100644
--- a/Roadmap.mdwn
+++ b/Roadmap.mdwn
@@ -23,6 +23,16 @@ new extent field (e.g. compress with given compression type, for the
 Most of the design and implementation for this is complete - there is still
 some work related to the triggers code remaining.
 
+## tmpdir support
+
+Add a directory option for using it as a tmpdir - the contents will be deleted
+on every mount.
+
+Since the contents won't be needed after an unclean shutdown, there's no need
+for fsync() to do anything - this option will also turn fsync() into a noop,
+and without the fsync buffered IO will only be flushed on memory reclaim -
+meaning, tmpdir directories should perform just as well as a tmpfs.
+
 ## Compression
 
 We'd like to add multithreaded compression, for when a single thread is doing
@@ -76,20 +86,6 @@ We also want to add more counters to the inode. Right now in the inode we only
 track sectors used as fallocate would see them - we should add counters that
 take into account replication and compression.
 
-## Number of devices in a filesystem:
-
-Currently, we're limited to a maximum of 64 devices in a filesystem. It would be
-desirable and not much work to lift that limit - it's not encoded in any on disk
-data structures, just in memory bitmasks. After that we'll support 256 devices,
-and to go past that we'll need another, larger `bch_extent_ptr` type and a new
-superblock section for larger device index fields.
-
-`bch_extent_ptr` uses 44 bits for the offset field (in units of 512 byte
-sectors), giving us a current maximum device size of 8 petabytes. We already
-have code for different types of checksum fields within an extent for different
-size checksums, so adding support for a new, larger extent ptr type will be
-fairly trivial.
-
 ### Device management:
 
 We need a concept of "failure domains", and perhaps something more, for managing
@@ -115,6 +111,17 @@ which means that the failure of _any_ three devices would lead to loss of data.
 
 A feature that addresses these issues still needs to be designed.
 
+### Send and receive
+
+Like ZFS and btrfs have, we need it to. This will give us the ability to
+efficiently synchronize filesystems over a network for backup/redundancy
+purposes - much more efficient than rsync, and it'll pair well with snapshots.
+
+Since all metadata exists as btree keys, this won't be a huge amount of work
+to implement: we need a network protocol, and then we need to scan and send
+for keys newer than version number X (if making use of key version numbers),
+or keys newer than a given snapshot ID.
+
 ### Support for sub-block size writes
 
 Devices with larger than 4k blocksize are coming, and this is going to result
diff --git a/index.mdwn b/index.mdwn
index 721a5b6..2d12933 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -13,6 +13,9 @@ from a modern filesystem.
 * [[Compression]]
 * [[Encryption]]
 * [[Snapshots]]
+* Nocow mode
+* Reflink
+* Extended attributes, ACLs, quotas
 * Scalable - has been tested to 100+ TB, expected to scale far higher (testers wanted!)
 * High performance, low tail latency
 * Already working and stable, with a small community of users
@@ -23,17 +26,22 @@ from a modern filesystem.
 * [[User manual|bcachefs-principles-of-operation.pdf]]
 * [[FAQ]]
 
-## Debugging tools
+## Repositories
+
+[[https://evilpiepirate.org/git/bcachefs.git]]
+[[https://evilpiepirate.org/git/bcachefs-tools.git]]
+
+## [[Debugging tools|Debugging]]
 
 bcachefs has extensive debugging tools and facilities for inspecting the state
-of the system while running - [[debugging]].
+of the system while running.
 
 ## Development tools
 
 bcachefs development is done with
 [[ktest|https://evilpiepirate.org/git/ktest.git]], which is used for both
-interactive and automated testing, with a large test suite -
-[[test dashboard|https://evilpiepirate.org/~testdashboard/ci]].
+interactive and automated testing (including code coverage analysis), with a
+large test suite: [[dashboard|https://evilpiepirate.org/~testdashboard/ci]].
 
 ## Philosophy, vision
 
diff --git a/sidebar.mdwn b/sidebar.mdwn
index e94c7fe..53484d0 100644
--- a/sidebar.mdwn
+++ b/sidebar.mdwn
@@ -1,15 +1,18 @@
-### bcachefs developer documentation
-  * [[Architecture]]
-  * [[BtreeIterators]]
-  * [[BtreeNodes]]
-  * [[BtreeWhiteouts]]
-  * [[Encryption]]
-  * [[Transactions]]
-  * [[Snapshots]]
-  * [[Allocator]]
-  * [[Fsck]]
-  * [[Roadmap]]
-  * [[Wishlist]]
-  * [[TestServerSetup]]
-  * [[StablePages]]
-  * [[October 2022 talk for Redhat|bcachefs_talk_2022_10.mpv]]
+### Other useful links
+* [[Roadmap]]
+* [[Wishlist]]
+* [[User manual|bcachefs-principles-of-operation.pdf]]
+
+### Developer documentation
+* [[Architecture]]
+* [[BtreeIterators]]
+* [[BtreeNodes]]
+* [[BtreeWhiteouts]]
+* [[Encryption]]
+* [[Transactions]]
+* [[Snapshots]]
+* [[Allocator]]
+* [[Fsck]]
+* [[TestServerSetup]]
+* [[StablePages]]
+* [[October 2022 talk for Redhat|bcachefs_talk_2022_10.mpv]]