Re: [Bug] Inaccessible, unerasable file

[Max Muster <tastky@gmail.com>]

Hi,

I don't recall anything like a blackout, but since I like to run new
software that's still in development, I have had a fair share of system
crashes.

As far as I'm aware this is the only file on the partition to ever
become corrupted at the file system level, though.

The repository was a simple (shallow) git clone of Google's gyp,
available here:

https://chromium.googlesource.com/external/gyp.git

Such being the case, I have no need to restore the file, but being able
to have it properly deleted would be nice.

Yours
tastky

On 22.10.2013 13:09, Jaegeuk Kim wrote:
> Hi,
>
> Thank you for the report.
>
> 2013-10-19 (토), 19:36 +0200, Max Muster:
>> There's a broken, ie. inaccessible and unerasable file on my f2fs
>> partition (2nd partition with 21GB on a Corsair Flash Voyager GT USB 3.0
>> 32GB). ls reports:
>>
>>   >cannot access shared.h: Input/output error
>>   >total 0
>>   >-????????? ? ? ? ?            ? shared.h
>>
>> The file has been on the partition for a couple of months already. I
>> didn't report sooner as I could/can move its folder (but not the file
>> itself) where it doesn't bug me and it doesn't appear to affect anything
>> else.
>>
>> (I'm currently running Linux v3.12-rc5 with post-3.12 f2fs patches
>> applied manually.)
>>
>> The partition is used primarily to store source code and as cache for
>> ccache. I don't recall ever fiddling with this file directly; it
>> probably happened during updating its repository or deleting just that.
>>
>> f2fs-tools's fsck (current git 2ad1fcd800) doesn't appear to do anything
>> and aborts after some 30 seconds with:
>>
>>   >Info: sector size = 512
>>   >Info: total sectors = 42106880 (in 512bytes)
>>   >[fsck_chk_node_blk: 195] block addr [0xa40ae59]
>>   >
>>   >Assertion failed!
>>   >[fsck_chk_node_blk: 195] ni.blk_addr < F2FS_RAW_SUPER(sbi)->block_count
>>
>> If you would like me to post further info, please tell me which; I've
>> got no idea how to further debug this.
>
> Um, I've never seen this kind of error so far.
>  From the result of fsck, it seems that the inode of shared.h was lost.
> So, currently, there is no way to recover that inode and its data
> simply.
> It may need scan the whole partition to find the stale inode block.
>
> Two questions.
> - Have you experienced any sudden power-off before?
> - Can I test with the repository having the shared.h that you used?
>    (I'd like to do a simple test storing that repository.)
>
> Thanks,
>

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel