Tomas M: > > The struct of a xino file is simple, just a sequence of aufs inode > > numbers which is indexed by the lower inode number. > > In the above sample, assume the inode number of /ro/fileA is i111 and > > aufs assigns the inode number i999 for fileA. Then aufs writes 999 as > > 4(8) bytes at 111 * 4(8) bytes offset in the xino file. > > I think it is worth mentioning that the xino file, if I understand it correctly, is a 'sparse file', that means it is full of 'holes' and doesn't consume as much disk space as it might appear. That is right. Thank you for pointing out. > In my opinion, the current xino-file approach is not much usable on filesystems which do not support sparse files (for example, if you wish to union two vfats), since some 'seeks' would probably write a lot of nulls. But I am not any kernel developer so I don't even know if there exists any filesystem which would be unable to support sparse files (except the mentioned VFAT, of course). Aufs creats the xino files on the first writable branch. If it consumes disk space for holes, then an aufs mount option 'xino=<path>' may be useful. I will update my local documents. Thank you. J. R. Okajima -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
