8

I hope I've got this right: A file's inode contains data such as inode number, time of last modification, ownership etc. – and also the entry: »deletion time«. Which made me curious:
Deleting a file means removing it's inode number, thus marking the storage space linked to it as available. There are tools to recover (accidentally) deleted files (e.g. from a journal, if available). And I know the stat command.

Question

What does a "deleted file" entry look like in the journal?

My guess is a quite unspectacular looking output as such as if issued the stat command.

I know that deleting a file and trying to recover it would be a first-hand experience, but then I'm not at a point where I could do this without outside help and I want to understand exactly what I'm doing. Getting into data resurrection would be sidetracking for me at the moment, as I try to get a firm grip on the basic stuff... I'm not lazy, this isn't homework, this is for private study.

Improve this question

2 Answers 2

Reset to default
6

When a file or directory is "deleted" its inode number is removed from the directory which contains the file. You can see the list of inodes that a given directory contains using the tree command.

Example

$ tree -a -L 1 --inodes . . |-- [9571121] dir1 |-- [9571204] dir2 |-- [9571205] dir3 |-- [9571206] dir4 |-- [9571208] dir5 |-- [9571090] file1 |-- [9571091] file2 |-- [9571092] file3 |-- [9571093] file4 `-- [9571120] file5 5 directories, 5 files

Links

It's important to understand how hardlinks work. This tutorial titled: Intro to Inodes has excellent details if you're just starting out in trying to get a fundamental understanding of how inodes work.

excerpt

Inode numbers are unique, but you may have noticed that some file name and inode number listings do show some files with the same number. The duplication is caused by hard links. Hard links are made when a file is copied in multiple directories. The same file exists in various directories on the same storage unit. The directory listing shows two files with the same number which links them to the same physical on te storage unit. Hard links allow for the same file to "exist" in multiple directories, but only one physical file exists. Space is then saved on the storage unit. For example, if a one megabyte file is placed in two different directories, the space used on the storage is one megabyte, not two megabytes.

Deleting

That same tutorial also had this to say about what happens when a inode is deleted.

Deleting files causes the size and direct/indirect block entries are zeroed and the physical space on the storage unit is set as unused. To undelete the file, the metadata is restored from the Journal if it is used (see the Journal article). Once the metadata is restored, the file is once again accessible unless the physical data has been overwritten on the storage unit.

Extents

You might want to also brush up on extents and how they work. Again from the linux.org site, another good tutorial, titled: Extents will help you get the basics down.

You can use the command filefrag to identify how many extents a given file/directory is using.

Examples

$ filefrag dir1 dir1: 1 extent found $ filefrag ~/VirtualBox\ VMs/CentOS6.3/CentOS6.3.vdi /home/saml/VirtualBox VMs/CentOS6.3/CentOS6.3.vdi: 5 extents found

You can get more detailed output by using the -v switch:

$ filefrag -v dir1 Filesystem type is: ef53 File size of dir1 is 4096 (1 block of 4096 bytes) ext: logical_offset: physical_offset: length: expected: flags: 0: 0.. 0: 38282243.. 38282243: 1: eof dir1: 1 extent found

NOTE: Notice that a directory always consumes at a minimum, 4K bytes.

Giving a file some size

We can take one of our sample files and write 1MB of data to it like this:

$ dd if=/dev/zero of=file1 bs=1k count=1k 1024+0 records in 1024+0 records out 1048576 bytes (1.0 MB) copied, 0.00628147 s, 167 MB/s $ ll | grep file1 -rw-rw-r--. 1 saml saml 1048576 Dec 9 20:03 file1

If we analyze this file using filefrag:

$ filefrag -v file1 Filesystem type is: ef53 File size of file1 is 1048576 (256 blocks of 4096 bytes) ext: logical_offset: physical_offset: length: expected: flags: 0: 0.. 255: 35033088.. 35033343: 256: eof file1: 1 extent found

Deleting and recreating a file quickly

One interesting experiment you can do is to create a file, such as file1 above, and then delete it, and then recreate it. Watch what happens. Right after deleting the file, I re-run the dd ... command and file1 shows up like this to the filefrag command:

$ filefrag -v file1 Filesystem type is: ef53 File size of file1 is 1048576 (256 blocks of 4096 bytes) ext: logical_offset: physical_offset: length: expected: flags: 0: 0.. 255: 0.. 255: 256: unknown,delalloc,eof file1: 1 extent found

After a bit of time (seconds to minutes pass):

$ filefrag -v file1 Filesystem type is: ef53 File size of file1 is 1048576 (256 blocks of 4096 bytes) ext: logical_offset: physical_offset: length: expected: flags: 0: 0.. 255: 38340864.. 38341119: 256: eof file1: 1 extent found

The file finally shows up. I'm not entirely sure what's going on here, but it looks like it takes some time for the file's state to settle out between the journal & the disk. Running stat commands shows the file with an inode so it's there, but the data that filefrag uses hasn't been resolved so we're in a bit of a limbo state.

Improve this answer
2
  • Nothing you mention here has anything to do with the journal. What you are seeing with filefrag is the delayed allocation feature in effect. The kernel doesn't allocate the blocks until it goes to write the data to the disk. At the time you run filefrag, the data is still sitting in the cache, so the kernel hasn't decided where it is going to put it yet. Commented Dec 11, 2013 at 14:59
  • @psusi - I knew I was dancing around the actual details, is there any way to peek inside the Kernel to see more of the state of things? I didn't find much in the way of tools related to the journal. Commented Dec 11, 2013 at 15:03
0

Deleting a file involves a few steps:

  1. Mark the name in the directory as deleted
  2. Decrement the link count in the inode
  3. If the link count is now zero, set the deleted time and
  4. Mark the data blocks as free in the bitmap

So the journal "looks like" this sequence.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.