| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Mon, 23 Feb 2009 23:23:23 +0900 From: hooanon05@...oo.co.jp To: Tomas M <tomas@...x.org> Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [RFC 2/8] Aufs2: structure 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-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists