Re: Packing bug?

> On Friday 11 February 2005 13:20, Matt Hamilton wrote:
>
>> but I'm
>> guessing that somehow the same path comes up again
>
> That would do it.... I wonder how it happens?
>
> On reiserfs, I assume? I understand that reiserfs opendir/readdir
presents inodes in the order they are stored in the filesystem tree,
which is basically the same as filename hash order. A renamed file might
come up twice, but one that is not renamed should not. The files that we
care about
> never seeing twice are not renamed, therefore this should be safe.

No, this is not reiserfs, this is on VXFS, on Solaris:

> uname -a
SunOS lon3800xus 5.8 Generic_108528-27 sun4u sparc SUNW,Sun-Fire-V440
> /sbin/mount | grep cmsU
/cmsU on /dev/vx/dsk/Udatadg/cms01U
read/write/setuid/delaylog/largefiles/ioerror=mwdisable/dev=45407d0 on Tue
Oct 26 14:23:21 2004

The parition is mounted via fibre channel from an EMC array.

> Conventional unix filesystems that use linear directory searches (eg
ext2) can
> show a file twice if it is renamed to a longer name that does not fit in
the
> old directory slot. Again, safe.

I don't know a huge amount about VXFS other than it does dynamic inode
allocation.  I assume it is journalling, but not sure.

> On other filesystems I can imagine this not being safe :-( It might also be
> unsafe if there are other concurrent changes in the same directory.
DirectoryStorage is in snapshot mode at that time, but there could be
external triggers.
>
> Hmmmm, this does all seem uncomfortably close to a danger zone.

Yeah, tell me about it :)

>> So the above logic seems to say: 'if the file is marked and we are not in
>> pretend mode, unmark it'.  Doesn't this seem a bit odd?  I assume this is
>> such that all files are unmarked by the end of the packing,
>
> Yes, it is a performance optimisation. If we dont do it now, that bit
will need to get flipped in pass 1 in the next pack (unmark_all, called
from filesystem.mark_context). It is cheaper to do it sooner while the
inode is already in memory.
>
> It is a pure optimisation, so I think it would be safe to remove that
branch.
> I will review this code later today to confirm this solution.

I'll give it a try here and let you know how it goes.

> Thanks for the detective work. Good find.

No problem :)

-Matt

-- 
Matt Hamilton                                         [email protected]
Netsight Internet Solutions, Ltd.          Business Vision on the Internet
http://www.netsight.co.uk                               +44 (0)117 9090901
Web Design | Zope/Plone Development and Consulting | Co-location | Hosting





-- 
Matt Hamilton                                         [email protected]
Netsight Internet Solutions, Ltd.          Business Vision on the Internet
http://www.netsight.co.uk                               +44 (0)117 9090901
Web Design | Zope/Plone Development and Consulting | Co-location | Hosting




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click