On Tue, Dec 7, 2010 at 11:29 AM, Chris Mason <chris.ma...@oracle.com> wrote: > Excerpts from Mike Fedyk's message of 2010-12-07 14:16:55 -0500: >> On Tue, Dec 7, 2010 at 10:44 AM, Chris Mason <chris.ma...@oracle.com> wrote: >> > Excerpts from Tsutomu Itoh's message of 2010-12-07 02:59:52 -0500: >> >> Hi, >> >> >> >> I think that the disk allocation size of each file becomes a monotone >> >> increase >> >> when the file is made. >> >> But, it sometimes return to 0. Is it correct? >> > >> > Well, there's a window during the processing of delayed allocation where >> > we don't have the bytes recorded as delalloc and we don't have the bytes >> > recorded in the inode yet. That's why they are showing up as zero. >> > >> > We don't call inode_add_bytes() until after we insert the extent, but we >> > drop the delalloc byte count on the file before the IO is done. >> > >> > Fixing it will be a little tricky because all the extent accounting >> > assumes the inode_add_bytes happens at extent insertion time. >> > >> >> How does opening the inode with O_APPEND during this window know where >> to write the bytes? If it's a pointer/cursor to the EOF then that >> size could be used during the window. Is that right? > > This counter records the number of blocks allocated to the file, and > reading it with ls -l or stat is somewhat racey by nature. Most of the > time its fine, btrfs just has a really big window where the results from > ls -l seem wrong. >
I see. Is it using per-cpu vars or something similar? > But, the counter really means nothing to the btrfs internals. When we > do file operations we go based on the extent pointers we find in the > tree and i_size (i_size is strictly maintained). > Would it be too heavy of an operation to have stat walk the btrfs tree to get its data? > The incorrect results are confusing but they don't hurt the metadata > itself. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
