Data not freed after remove?

Data not freed after remove?

[Sven Eisenberg]

Hi MTD list

I've seen a problem on our embedded device with UBI/UBIFS. Kernel
2.6.31+UBI/UBIFS at level ~3.10.y.

In short summary what i see is:

1. Deleting a folder with a big file (680MB) in a partition of 892MB size.
2. Perform a sync.
3. Read available free space with statvfs, fails. It reports the same
value as before deletion.
4. remount partition as ro, fails. But no message in dmesg.

Is there any reason/bug known that would cause this behavior?
I know this can happen, when there i an open filedescriptor to the file.
So i verified and this is not the case for me.

Thanks in advance, Sven Eisenberg




-- 

*Sven Eisenberg*

 

novero GmbH | Meesmannstr. 103 | 44807 Bochum | Germany | Amtsgericht
Bochum | HRB 16050 | Umsatzsteueridentifikationsnummer: DE 814973142 |
Geschäftsführer: Steven E. Brown, Michael Heinz Michels, Jacobus
Gerhardus du Plessis

 

A Laird business www.lairdtech.com <http://www.lairdtech.com>

Re: Data not freed after remove?

[Sven Eisenberg]

Hi Richard and all

On 01.06.2016 13:55, Richard Weinberger wrote:
> ...
> What is the return code of mount()?
>
> > Is there any reason/bug known that would cause this behavior?
>
> Hmm, I don't know.
>
> > I know this can happen, when there i an open filedescriptor to the file.
> > So i verified and this is not the case for me.
>
> Yes, remount can fail if the volume is busy. That's why i wonder what
> the return code is.

Yes the volume is busy:
mount -o remount,ro /mnt/point  = -1 EBUSY (Device or resource busy)

I could not yet identify why it is in busy state.

I added some code to check for open file descriptors. I built a test
application which simulates the sequence. But it runs without a problem.
Can i get informations from the kernel, what file or state causes the
busy state?

br, Sven Eisenberg

Re: Data not freed after remove?

[Richard Weinberger]

Sven,

On Fri, Jun 3, 2016 at 10:16 AM, Sven Eisenberg
<sven.eisenberg@novero.com> wrote:
>> Yes, remount can fail if the volume is busy. That's why i wonder what
>> the return code is.
>
> Yes the volume is busy:
> mount -o remount,ro /mnt/point  = -1 EBUSY (Device or resource busy)
>
> I could not yet identify why it is in busy state.
>
> I added some code to check for open file descriptors. I built a test
> application which simulates the sequence. But it runs without a problem.
> Can i get informations from the kernel, what file or state causes the
> busy state?

EBUSY can have many reasons. I'd guess an open file in RW mode.
Did you try lsof?

-- 
Thanks,
//richard