linux-ext4 - Re: Question about ext4 journal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 24 Oct 2015 12:10:48 +0900
From:	Masanari Iida <standby24x7@...il.com>
To:	Amir Goldstein <amir73il@...il.com>
Cc:	Ext4 <linux-ext4@...r.kernel.org>
Subject: Re: Question about ext4 journal

On Fri, Oct 23, 2015 at 3:22 PM, Amir Goldstein <amir73il@...il.com> wrote:
> On Fri, Oct 23, 2015 at 7:04 AM, Masanari Iida <standby24x7@...il.com> wrote:
>>
>> As I see the contents of journal entries in EXT4 using debugfs(8),
>> the journal entries are growing when creating or deleting the files.
>> I am curious to know what make the system to remove journal entries
>> while mounted the fs.
>
> it's called the orphan inode list.
> every deleted inode gets inserted into the list, then deleted, then
> removed from orphan inodes list.
> on mount, fs starts by "playing" the journal, then clearing the orphan
> inodes list
>
Hello Amir,   Ted,

My test case
(1)   Create a small file by vi.  (about 1000bytes)
(2)   Delete the file "rm -f"
===== within 1 min =====
(3)   Create a small file again with same file name as (1).
=====  12 hours of no operation ,  no umount, no mount, no fsck ======
(4)  Snapshot ( created by storage device )
===== some days ======
(5)  Run fsck the fs image and mount the fs

I understand that in step2,  when the file delete happen,
   inode gets insert into orphan list,
         delete the file data
             inode gets deleted from orphan list.

My wild guess is
file was created in inode #100 (for example),
it was deleted and inode #100 moved to orphan list.
The inode #100 was re-used in step 3.
snapshot taken.
Run fsck.   inode #100 was found in orphan list, so the file with same
inode was deleted during fsck.

Did we have such trouble during 2.6.32 time?

Regards,
Masanari
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html