xfs
[Top] [All Lists]

Re: Hello, I have a question about XFS File System

To: stan@xxxxxxxxxxxxxxxxx, Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: Hello, I have a question about XFS File System
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Fri, 07 Mar 2014 21:24:53 -0600
Cc: Yongmin <dev.yongmin@xxxxxxxxx>, "xfs@xxxxxxxxxxx" <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <531A7BB8.5090201@xxxxxxxxxxxxxxxxx>
References: <195DE8C60CE24A62A71911FDE0B0DC97@xxxxxxxxx> <5318DB01.2040102@xxxxxxxxxxxxxxxxx> <279D0A265E5D4AF5B099BFAD4E8B1700@xxxxxxxxx> <531A4600.7050906@xxxxxxxxxxxxxxxxx> <20140307230915.GS6851@dastard> <531A7BB8.5090201@xxxxxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
On 3/7/14, 8:08 PM, Stan Hoeppner wrote:
> On 3/7/2014 5:09 PM, Dave Chinner wrote:
>> On Fri, Mar 07, 2014 at 04:19:44PM -0600, Stan Hoeppner wrote:
>>> Please reply to the mailing list as well as the individual.
>>>
>>> Note that you stated:
>>>
>>> '...the concentrated part of mine is "Deleted File Recovery"'
>>>
>>> On 3/6/2014 10:02 PM, Yongmin wrote:
>>>>
>>>> Yes! there are no actual file data in journaling part.
>>>>
>>>> BUT, by analyzing journaling part, we can get a Inode Core Information 
>>>> which was deleted.
>>>> In Inode Core, there are many information about the actual data, i.e. 
>>>> start address, file length etc.
>>>
>>> Analyzing the journal code may inform you about structures, but it won't
>>> inform you about on disk locations of the structures and how to find
>>> them.  If a file has been deleted, no information about that is going to
>>> exist in the journal for more than a few seconds before the transaction
>>> is committed and the entry removed from the journal.
>>
>> Well, we don't actually "remove" information from the log. We update
>> pointers that indicate what the active region is, but we never
>> physically "remove" anything from it. IOWs, the information is in
>> the journal until it wraps around and is over written by new
>> checkpoints....
> 
> Quite right.  I sacrificed some technical accuracy to drive home the
> larger point, that the journal shouldn't be relied upon for forensic
> retrieval of deleted files.
> 
>>>> By using those information, Recovering delete file can be done.
>>>>
>>>> So the analysis of Journaling part is absolutely needed.  
>>>
>>> I disagree.  Again, the journal log is unrelated to "deleted file
>>> recovery" in a forensics scenario.
>>>
>>> I think Dave and Jeff both missed the fact that you're interested only
>>> in deleted file recovery, not in learning how the journal works for the
>>> sake of learning how the journal works.
>>
>> Oh, no, I saw it and didn't think it was worth commenting on. I
>> think it's a brain-dead concept trying to do undelete in the
>> filesystem. "recoverable delete" was a problem solved 30 years ago -
>> it's commonly known as a trash bin and you do it in userspace with a
>> wrapper around unlink that calls rename(2) instead. And then "empty
>> trashbin" is what does the unlink and permanently deletes the files.
>>
>> Besides, from a conceptual point of view after-the-fact filesystem
>> based undelete is fundamentally flawed. i.e.  the journal is a
>> write-ahead logging journal and so can only be used to roll the
>> filesystem state forwardi in time. Undelete requires having state
>> and data in the journal that allows the filesystem to be rolled
>> *backwards in time*. XFS simply does not record such information in
>> the log and so parsing the log to "undelete files by transaction
>> rollback" just doesn't work.
> 
> Sometimes context gets lost.  In his first paragraph he stated he's a
> graduate student and his research area is digital forensics.  So the
> discussion about "deleted file recovery" needs to be in the forensics
> context.  As you explain above, and as Greg Freemyer pointed out,
> looking at filesystem metadata or journals for information that will
> assist in the recovery of previously deleted files is usually not going
> to be fruitful.

Well, I think that's a good point.  "Looking at the log to see if there
are any clues for manual recovery" is a very different problem from
"Use the log for automated, guaranteed successful undelete" :)

-Eric

<Prev in Thread] Current Thread [Next in Thread>