diff --git a/FAQ.md b/FAQ.md
index 7502391..6727f65 100644
--- a/FAQ.md
+++ b/FAQ.md
@@ -32,12 +32,11 @@ A: Yes.  Follow [the standard quickstart instructions](http://tahoe-lafs.org/sou
 
 A: Not directly. Each storage server has a single "base directory" which we abbreviate as $BASEDIR. The server keeps all of its shares in a subdirectory named $BASEDIR/storage/shares/ . (Note that you can symlink  this to whatever you want: you can run most of the node from one place, and store all the shares somewhere else). Since there's only one such subdirectory, you can only use one filesystem per node.On the other hand, shares are stored in a set of 1024 subdirectories of that one, named $BASEDIR/storage/shares/aa/, $BASEDIR/storage/shares/ab/, etc. If you were to symlink the first third of these to one filesystem, the next third to a second filesystem, etc, (hopefully with a script!), then you'd get about 1/3rd of the shares stored on each disk. The "how much space is available" and space-reservation tools would be confused, but basically everything else should work normally.
 
-**Q: Would it make sense to just use RAID-0 and let Tahoe-LAFS deal with the redundancy?**
+**Q: Would it make sense to not use any RAID and let Tahoe-LAFS deal with the redundancy?**
 
 A: The Allmydata grid didn't bother with RAID at all: each Tahoe-LAFS storage server node used a single spindle.
-The "RAID and/or Tahoe-LAFS" question depends upon how much you trust RAID vs how much you trust Tahoe-LAFS, and how expensive the different forms of
-repair would be. Tahoe-LAFS can correctly be thought of as a form of "application-level RAID", with more flexibility than the usual RAID0/4/5
-styles (I think RAID-0 is equivalent to 1-of-2 encoding, and RAID-5 is like 2-of-3).
+
+The answer depends on how expensive the different forms of repair would be. Tahoe-LAFS can correctly be thought of as a form of "application-level RAID", with more flexibility than the usual RAID-1/4/5 styles (RAID-1 is equivalent to 1-of-2 encoding, and RAID-5 is like 3-of-4).
 
 Using RAID to achieve your redundancy gets you fairly fast repair, because it's all being handled by a controller that sits right on top of
 the raw drive. Tahoe-LAFS's repair is a lot slower, because it is driven by a client that's examining one file at a time, and since there are a lot of
@@ -57,9 +56,6 @@ it becomes a tradeoff between money (number of Tahoe-LAFS storage nodes, what so
 much those disks cost, how many computers you need to host them, how much bandwidth you spend doing upload/download/repair), bandwidth costs,
 read/write performance, and probability of file loss due to failures happening faster than repair.
 
-In addition, Tahoe-LAFS's current repair code is not particularly clever: it doesn't put the new shares in exactly the right places, so you can
-easily get shares doubled up and not distributed as evenly as if you'd done a single upload. This is being tracked in ticket #610.
-
 '''Q: Suppose I have a file of 100GB and 2 storage nodes each with 75GB available, will I be able to store the file or does it have to fit
 within the realms of a single node?'''