On Wed, 7 May 2003, OGAWA Hirofumi wrote:
> Peder Stray <peder@ifi.uio.no> writes:
>
> > The problem is verry inconsistent as i said earlier, so the number of
> > files in a directory doesn't seem to matter, nor do the depth in the
> > directory structure. Some files i manage to copy yo the disk, some files i
> > don't... I havent managed to find any pattern in what files this affects.
>
> I meant, "directory entry pointer" is position of the directory entry
> in the _partition_. like the following,
aha, that was what you ment...
> in fs/fat/misc.c:fat__get_entry()
>
> offset &= sb->s_blocksize - 1;
> *de = (struct msdos_dir_entry *) ((*bh)->b_data + offset);
> *ino = (sector << sbi->dir_per_block_bits) + (offset >> MSDOS_DIR_BITS);
> ^^^
>
> This is used for _updates_ (not create) of the directory entry. And
> there is a possibility of cause of the problem which you said. If my
> guess is right and a partition will be splited small, a problem will
> not occur.
>
> In short, I think it's the bug of fat driver and it's needed the fix.
So effeivly all directories located over a given boundry on the disk would
be affected? Would removing a file written to the disk early and making a
few directories insted fix some of the problems... Have to try that...
Need to find a way to get back the 17G of allocated but unsuable data
too...
-- Peder Stray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 07 2003 - 22:00:28 EST