On Wed, Nov 30, 2011 at 10:34 AM, Emmanuel Dreyfus <manu@xxxxxxxxxx> wrote: > Anand Avati <anand.avati@xxxxxxxxx> wrote: > >> Yes, that was the very intention of making the inode number a >> derivation of the GFID instead of the backend inode number, so that >> brick addition/replacement does not impact its stability. > > I tested it and it does not work as expected on 3.2.5. add-brick and > rebalance migrate-data do change inode numbers. > > Inode numbers, at the beginnig > /pfs 1 > /pfs/manu 12472916913858460615 > /pfs/manu/openssl-0.9.8o.tar 12709833430099732973 > > After add-brick, everything changed: > /pfs 1 > /pfs/manu 6499089754007369614 > /pfs/manu/openssl-0.9.8o.tar 6972922786489914330 > > After rebalance fix-layout (nothing changed) > /pfs 1 > /pfs/manu 6499089754007369614 > /pfs/manu/openssl-0.9.8o.tar 6972922786489914330 > > After rebalance migrate-data (file changed but not directory) > /pfs 1 > /pfs/manu 6499089754007369614 > /pfs/manu/openssl-0.9.8o.tar 4597243647138552351 The backporting of the gfid-derived inode number is incomplete in 3.2 as the itransforms are not NOP'ed. We will fix this. Avati
