On Mon, Feb 18, 2013 at 04:20:58PM -0700, Tony Plack wrote: > Chris and team, hats off on the RAID5/6 being at least experimental. > I have been following your work for a year now, and waiting for these > days. > > I am trying to get my head rapped around the architecture for BTRFS > before I jump in and start recommending code changes to the branch. > > What I am trying to understand is the comments in the GIT commit which > state: > > Read/modify/write is done after the higher levels of the filesystem have > prepared a given bio. This means the higher layers are not responsible > for building full stripes, and they don't need to query for the topology > of the extents that may get allocated during delayed allocation runs. > It also means different files can easily share the same stripe. > > As I understand it, what we are doing is trying to hide the underlying > extents architecture to gain some advantages in the higher level code. > I have been digging in the code, and believe I know the answer to this > question. So by "higher levels" does this mean that RMW, snapshots, > checksums and duplicate detection are all unaware of RAID > architecture? Yes, although the allocator is aware of the raid code, and the raid code is aware that the higher levels are doing copy-on-write. They also share the same transaction subsystem, at least until my parity logging code is complete. Longer term the two will cooperate more. For example, when we trigger read/modify/write in RAID because a sub-stripe write was made to a large file, we might as well use adjacent blocks from that file to fill the new stripe. This will reduce a lot of complexity in terms of small extent overhead in the rest of the code. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
