> manudagur 25. jznm 2001 21:20, ~z skrifapir:
> >
> > Ah, sorry I should have specified that you do this on one of the files
> > which appears to be oversized after the untar, the directory itself is
> > not really interesting. Sorry about that, I will go look at your output.
> > The 1 minute thing is interesting I will have to think about that.
> >
>
> Ah, but that's just it... the files are all *correct* size... It's the
> *link* count in the listing that's a bit off... you can see this by taking a
> diff between xfs-remount and xfs listings. They show, that each directory in
>
> the listing, where the sizes are too large, is due to that each directory has
>
> 4 links in it?
Hmm, there are two things going on, one being that the size field in
a directory is not getting updated when we add new entries to it. XFS
allows small directories to live totally within the inode, they will
show up with a 0 in the first column of ls -ls, as the directory grows,
it gets too big to fit in the inode and we have to allocate a block for
it. It looks like the block count field in the inode stat output is not
getting updated correctly - the remount forces the upper layers to get the
information from the xfs inode again.
The second is that you are moving from a 1K block ext2 filesystem to a 4K block
xfs filesystem. This means that any file smaller that 4K will use 4K of
disk space. Summing the space usage shown by the first column of the ls output
between the ext2 numbers and the xfs after remount numbers shows you went from
7813K on ext2 to 10212K on xfs. If you made a 4K block ext2 filesystem which
appears to be the standard now, and untarred your archive there, the numbers
would probably be a lot closer.
I will go fix the block count in directories thing, it should be easy.
Steve
|