On 2010-09-09, at 10:38, Jan Kara wrote: > Sigh, sorry to bring this up again... I wanted to use the original patch > with the workaround you suggested but realized there's still a hole. The > new patched kernel will happily use extra inode space for xattrs for inode > 11 but if you mount the filesystem with older kernel it will reset > i_extra_size to zero and thus you'll lose the stored xattrs. > So to get out of this compatibility trap we'd have to accept xattrs in > the extended inode space but never store it there and after a sufficiently > long time, we could remove the workaround. But this seems not worth the > effort to me given we speak about a single inode and rather trivial > workaround in ext3_iget and ext3_new_inode. The old saying goes "Be strict in what you send, but generous in what you receive", so I think it makes sense that we allow reading xattrs from inode #11 (and also the root inode #2 is affected), and as you suggest we should only store these xattrs in external blocks. The unfortunate thing is that xatts on the root inode will probably be the most heavily used, but it will also most likely be in cache so it probably won't be a serious performance issue (it can't be any worse than it is today). While I think it would be slightly less complex to deny in-inode xattrs entirely, that doesn't give us any path toward actually removing this problem. Of course, I think in the next 6 months or so (once ext4 is the default on RHEL6, widely in use at Google, and available on SLES11 SP1) we should probably consider ext4 stable enough that we should consider removing ext3 entirely from the tree and just have the "ext3" filesystem type be handled by ext4 as well. Cheers, Andreas.-- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
