Charles,

I should have also mentioned that when I mount the yaffs partition I get a
number of messages(shown below).

   [root]mount /dev/mtdblock/1 /mnt
   end_request: I/O error, dev 1f:01 (mtdblock), sector 1
   ...
   end_request: I/O error, dev 1f:01 (mtdblock), sector 71
   /dev/mtdblock/1: Input/output error
   yaffs: Attempting MTD mount on 31.1, "1f:01"

Everything looks fine on the partition and these message occur every time
I mount this partition. Since I changed the nShortOpCaches to zero I no
longer see truncated files, but the messages persist... I'm not sure if
these messages would give further insight, but I thought I should mention
them none the less.

Thanks,
Eddie

> This is pretty wierd.
>
> The "short op" cache is a write-into cache. That is, the writes into the
> cache do not go all the way to flash, but reside in the cache until the
> file
> is flushed or closed.
>
> This sounds like the files are not being closed preoperly, but then I'd
> not
> expect the unmount to happen.
>
> I'll tinker some more....
>
> -- CHarles
>
> On Tuesday 25 January 2005 13:40, Eddie Dawydiuk wrote:
>> Charles,
>>
>> Thank you for the response, I set nShortOpCaches to zero, recompiled,
>> and
>> no longer see the problem with files being truncated....
>>
>> Thanks again,
>> Eddie
>>
>> > I did some testing to try understand better whether this might be a
>> yaffs
>> > thing or not.
>> >
>> > I created some files, unmounted yaffs, remounted yaffs and they were
>> the
>> > same.
>> >
>> > If yaffs is indeed losing the data in this case, then there are a few
>> > things
>> > that need to be debugged to find out what might be causing the problem
>> > here:
>> >
>> > 1) Is the short op cache enabled? The easy way to tell this is to look
>> in
>> > /proc/yaffs.  The short op cache only caches stuff which is not page
>> > aligned,
>> > so there is potential that this could be where lossy things are
>> > happening. You could try turning off the short op cache (set
>> > nShortOpCaches to zero in
>> > yaffs_fs.c).
>> >
>> > 2) Is ftpd using memory mapped writes?
>> >
>> > 3) Do you get the same lossy behaviour when you create files by other
>> > means
>> > (copy, editor, etc)?
>> >
>> > -- CHarles
>> >
>> > On Tuesday 25 January 2005 11:54, Michael Erickson wrote:
>> >> Eddie,
>> >>
>> >> 512-bytes is the size of a TFTP data transfer. The first (and should
>> be
>> >> only) transfer that is less than 512-bytes indicates the end of the
>> >> file.
>> >>
>> >> How are you verifying that the original upload is correct? Are you
>> using
>> >> an MD5SUM or other fingerprint?
>> >>
>> >> --mike
>> >>
>> >> Eddie Dawydiuk wrote:
>> >> > Hello yaffers,
>> >> >
>> >> > I have recently come across a strange problem while using the yaffs
>> >> > filesystem. If I upload a file via FTP(troll-ftpd-1.26) everything
>> >>
>> >> looks
>> >>
>> >> > ok with regard to the file uploading correctly. But as soon as I
>> >>
>> >> unmount
>> >>
>> >> > the partition and remount it the file is truncated to the nearest
>> 512
>> >> > byte block. I am using kernel version 2.4.26 and have merged in the
>> >>
>> >> most
>> >>
>> >> > recent mtd and yaffs releases. If anyone has any suggestions I
>> would
>> >> > really appreciate them.
>> >> >
>> >> > Thanks,
>> >> > Eddie
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > yaffs mailing list
>> >> > yaffs@stoneboat.aleph1.co.uk
>> >> > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
>> >
>> > _______________________________________________
>> > yaffs mailing list
>> > yaffs@stoneboat.aleph1.co.uk
>> > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
>
>