Hello zfs-discuss,
What will happen if I create a stripe pool of 3 disks, then create
somy symlinks and then overwrite one disk with 0s.
Ditto blocks should self-heal meta data so file systems will be
consistent. Now when it comes to symlinks...
I was looking into a ZFS code and it looks like if symlink dst name is
less than 56 in size it will be stored in znode bonus buffer so it
will be protected by ditto blocks and such symlinks should survive
above scenario. However if symlink dst name is longer than 56 bytes it
will be stored in a data block so I guess I won''t be able to read it,
right?
--
Best regards,
Robert mailto:rmilkowski at task.gda.pl
http://milek.blogspot.com
Robert Milkowski wrote:> Hello zfs-discuss, > > What will happen if I create a stripe pool of 3 disks, then create > somy symlinks and then overwrite one disk with 0s. > Ditto blocks should self-heal meta data so file systems will be > consistent. Now when it comes to symlinks... > > I was looking into a ZFS code and it looks like if symlink dst name is > less than 56 in size it will be stored in znode bonus buffer so it > will be protected by ditto blocks and such symlinks should survive > above scenario. However if symlink dst name is longer than 56 bytes it > will be stored in a data block so I guess I won''t be able to read it, > right?That''s correct. See also 6516171 zpl symlinks should have their own object type The new object type would be marked as metadata, and thus always be ditto''ed. --matt
Hello Matthew, Thursday, March 29, 2007, 2:23:38 AM, you wrote: MA> Robert Milkowski wrote:>> Hello zfs-discuss, >> >> What will happen if I create a stripe pool of 3 disks, then create >> somy symlinks and then overwrite one disk with 0s. >> Ditto blocks should self-heal meta data so file systems will be >> consistent. Now when it comes to symlinks... >> >> I was looking into a ZFS code and it looks like if symlink dst name is >> less than 56 in size it will be stored in znode bonus buffer so it >> will be protected by ditto blocks and such symlinks should survive >> above scenario. However if symlink dst name is longer than 56 bytes it >> will be stored in a data block so I guess I won''t be able to read it, >> right?MA> That''s correct. See also MA> 6516171 zpl symlinks should have their own object type MA> The new object type would be marked as metadata, and thus always be MA> ditto''ed. That''s really interesting! Is someone currently working on it? Any time frame? I would be really interested in this feature. btw: what about corner cases when you have a file systems with 100''s million of symlinks and basically nothing more. If above would be on by default (and I guess one couldn''t switch it off) in such a case fs will consume 2x space additional to lets say underlaying mirror - not everyone would be pleased I guess... ?? -- Best regards, Robert mailto:rmilkowski at task.gda.pl http://milek.blogspot.com
Hello Robert, Thursday, March 29, 2007, 11:37:48 AM, you wrote: RM> Hello Matthew, RM> Thursday, March 29, 2007, 2:23:38 AM, you wrote: MA>> Robert Milkowski wrote:>>> Hello zfs-discuss, >>> >>> What will happen if I create a stripe pool of 3 disks, then create >>> somy symlinks and then overwrite one disk with 0s. >>> Ditto blocks should self-heal meta data so file systems will be >>> consistent. Now when it comes to symlinks... >>> >>> I was looking into a ZFS code and it looks like if symlink dst name is >>> less than 56 in size it will be stored in znode bonus buffer so it >>> will be protected by ditto blocks and such symlinks should survive >>> above scenario. However if symlink dst name is longer than 56 bytes it >>> will be stored in a data block so I guess I won''t be able to read it, >>> right?MA>> That''s correct. See also MA>> 6516171 zpl symlinks should have their own object type MA>> The new object type would be marked as metadata, and thus always be MA>> ditto''ed. RM> That''s really interesting! Is someone currently working on it? Any RM> time frame? I would be really interested in this feature. RM> btw: what about corner cases when you have a file systems with 100''s RM> million of symlinks and basically nothing more. If above would be RM> on by default (and I guess one couldn''t switch it off) in such a RM> case fs will consume 2x space additional to lets say underlaying RM> mirror - not everyone would be pleased I guess... RM> ?? But metadata are compressed so probably it will consume less space... right? -- Best regards, Robert mailto:rmilkowski at task.gda.pl http://milek.blogspot.com