On 2011-03-31 09:53, Christoph Hellwig wrote: > Btw, how is the spnfs-block support supposed to work at all? > > fallocate creates unwritten extents, and I can't actually > spot a place that would later convert them to regular extents. It's supposed to work by committing the extents on layoutcommit. It's supposed to happen in the spnfs-block but it doesn't. Currently, the generic layer calls write_inode_now if the size changes and the fs is exported "sync" so my guess is that it works now only when the file is extended but not when writing in-place into holes. > And how does it work for filesystems without ->fallocate like > ext3? It doesn't. spnfs-block requires fs support for fallocate and fiemap. > And how do we prevent clients from reading uninitialized > blocks in areas allocated on the server but not written > to yet. Is there anything like unwritten extents in the > on the write protocol? Yes, there is, yet spnfs-block does not implement it as it was implemented essentially as a reference/testing tool. The protocol allows the server to provisionally allocate space on layoutget that the client can write into, privately. The clients changes only become visible to other clients when they are committed to the file on LAYOUTCOMMIT. This also allows implementing copy-on-write as the client can be given in the layout separate extents describing the readable copy of the block and the writeable one and the client participates in the copy-on-write process by copying the contents of the block before modifying it (or zeroing it out if it's just invalid). This is done at write_begin time on the client side. Benny > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
