[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE : ext3_free_blocks_sb when removing a more than 1GB file



Hello,

Thanks for your answer,  i will have a look to this tool and test my hardware ...

I have many similar keys and the problem appears systematically on these devices ...
So yes i could blame the hardware but it seems to be validated by the provide and I tried on a desktop linux ( embedded system problem) with a 2.6.32 and I dont have the issue.

I dont have the problem neither, when I change the block size of ext3. But I thnik that the performance can be decreased ( 4096 to 2048 ).

BR

Stephane
________________________________________
De : Andreas Dilger [adilger dilger ca]
Date d'envoi : vendredi 4 mars 2011 23:17
À : Stephane Cerveau
Cc : Eric Sandeen; ext3-users redhat com; Tristan Pateloup
Objet : Re: ext3_free_blocks_sb when removing a more than 1GB file

On 2011-03-04, at 11:07 AM, Stephane Cerveau wrote:
> I have several keys from the same brand, model and I have the same issue.
>
> When I said, a different key, it was a different brand.

I would typically blame the USB key.  Some cheap vendors use unreliable chips, and sometimes even mis-label e.g. 1GB flash as 2GB.

> At the end, it seems that ext2 is working fine!

Except I don't think ext2 is doing this bitmap validation at runtime, like ext3/4 is doing.

I'm not sure whether "badblocks" is verifying that the storage is behaving correctly (i.e. correct block addressing), or only whether it is able to write/read a particular sector on disk.

You could use a more advanced block device verification tool, like llverdev from Lustre, which writes a unique test pattern to every block, and then reads it back afterward.

> So maybe a problem in ext3 in 2.6.23 kernel ?!?
> I had a try on 2.6.32_27, I did not succeed to reproduce the issue.
>
> Do you know when ext3 is supposed to be stable ?

For 10+ years already.

> -----Original Message-----
> From: Eric Sandeen [mailto:sandeen redhat com]
> Sent: vendredi 4 mars 2011 18:59
> To: Stephane Cerveau
> Cc: ext3-users redhat com; Tristan Pateloup
> Subject: Re: ext3_free_blocks_sb when removing a more than 1GB file
>
> On 3/4/11 11:54 AM, Stephane Cerveau wrote:
>> Hi,
>>
>> Thanks for your answer.
>> Here is my steps:
>>
>> - mkfs.ext3 /dev/sda1
>> - mount /dev/sda1 /mnt/usb
>> - dd if=/dev/zero of=/mnt/usb/test_file bs=1M count=1025   ( the size is important)
>> - sync
>> - rm /mnt/usb/test_file
>
> Ok, I had the impression that you were removing the usb key at
> some point in the test, but I guess not.
>
>> Then many errors appears "Ext3-fs error ( device sda1): ext3_free_blocks_sb: bit already cleared for block xxxx"
>>
>> I tried to umount/mount the storage but its not working also.
>> I tried to check the device before removing the file, not working also.
>
> you mean that umount/mount/rm gives the same error?  As does umount/fsck/mount/rm ?
>
>> Indeed with another usb key it's working...
>> I'm using a kernel 2.6.23
>>
>> The problem does NOT appear with mkfs.ext2 /dev/sda1 before
>>
>> What do you advise to do ?
>
> Try a much newer kernel, first of all, to see if it's a known, fixed bug.
>
> But since it works on another usb key, I still tend to blame the hardware.
> "bit already cleared" makes it sound like it is reading zeros when it
> should not be.
>
> -Eric
>
>> BR
>>
>> Stephane.
>
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 5926 (20110304) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 5926 (20110304) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
> _______________________________________________
> Ext3-users mailing list
> Ext3-users redhat com
> https://www.redhat.com/mailman/listinfo/ext3-users


Cheers, Andreas







[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]