Dear all, First of all, it seems that I don't have any trouble with 2048 block size. I did a test with random size from 1024 to 2048 MB and I did not have the issue. Do you know which drawback I can have using this size ? ( except the speed ??) Concerning the key using 4096, it seems that I have some trouble also on a regular desktop with 2.6.23 and 2.6.28 kernel from ubuntu dist (live cd). But I don't have the issue on a ubuntu 2.6.32.27 generic kernel. Best regards. Stephane -----Original Message----- From: Stephane Cerveau [mailto:scerveau@xxxxxxxx] Sent: lundi 7 mars 2011 16:05 To: Alex Bligh; Eric Sandeen Cc: ext3-users@xxxxxxxxxx; Tristan Pateloup Subject: RE: ext3_free_blocks_sb when removing a more than 1GB file I tried to integrate this patch but it still does not work. http://gitorious.org/opensuse/kernel-source/commit/9f62d21f70e77298018f63c72e6d10a621ee6dcf I don't know how to debug it and don't understand why it happens only with large files. Is there anyone who can help me or advise me on how I could debug it ...Get some log or anything...:) I have to say that I'm working on an embedded system with a SH4 processor... Thanks Stéphane. -----Original Message----- From: Alex Bligh [mailto:alex@xxxxxxxxxxx] Sent: samedi 5 mars 2011 10:22 To: Stephane Cerveau; Eric Sandeen Cc: ext3-users@xxxxxxxxxx; Tristan Pateloup; Alex Bligh Subject: RE: ext3_free_blocks_sb when removing a more than 1GB file --On 4 March 2011 18:54:23 +0100 Stephane Cerveau <scerveau@xxxxxxxx> wrote: > 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. > Indeed with another usb key it's working... > I'm using a kernel 2.6.23 If it's that old, perhaps it is http://lkml.org/lkml/2008/11/14/121 fixed by http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.29 in 2.6.29 commit 7ef0d7377cb287e08f3ae94cebc919448e1f5dff I think. I am interested in this particular error. We see it very occasionally on 2.6.31 in an environment where we can be sure no underlying I/O error occurred (because it's on a VM whose dom0 uses iSCSI mapped to the domU's disk) and we would see error logging. It is normally during intense disk activity (unlike the OP), such as running "aptitude update", often while unlinking a file. It does not appear to happen on ext4. Unfortunately the result is that the disk goes readonly. Our current theory is that the disk got damaged in some way during a previous unclean shutdown that fsck did not fix. Is that possible? -- Alex Bligh __________ Information from ESET NOD32 Antivirus, version of virus signature database 5931 (20110306) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 5933 (20110307) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com _______________________________________________ Ext3-users mailing list Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users __________ Information from ESET NOD32 Antivirus, version of virus signature database 5933 (20110307) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 5936 (20110308) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com _______________________________________________ Ext3-users mailing list Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
