"The following patches have been in the -mm tree for a while, and I plan to push them to Linus when the 2.6.25 merge window opens," began Theodore Ts'o, offering the patches for review before they are merged. He explained that the patches introduce some of the final changes to the ext4 on-disk format, "ext4, shouldn't be deployed to production systems yet, although we do salute those who are willing to be guinea pigs and play with this code!" He continued:
"With this patch series, it is expected that [the] ext4 format should be settling down. We still have delayed allocation and online defrag which aren't quite ready to merge, but those shouldn't affect the on-disk format. I don't expect any other on-disk format changes to show up after this point, but I've been wrong before.... any such changes would have to have a Really Good Reason, though."
From: Theodore Ts'o <tytso@...>
Subject: ext4 merge plans for 2.6.25
Date: Jan 21, 11:01 pm 2008
The following patches have been in the -mm tree for a while, and I
plan to push them to Linus when the 2.6.25 merge window opens. With
this patch series, it is expected that ext4 format should be settling
down. We still have delayed allocation and online defrag which aren't
quite ready to merge, but those shouldn't affect the on-disk format.
I don't expect any other on-disk format changes to show up after this
point, but I've been wrong before.... any such changes would have to
have a Really Good Reason, though. (No, Abhishek Rai's changes
wouldn't count as an on-disk change, since they change layout choices,
but not anything that e2fsck would actually care about. We may try
merging those into ext4 and see how they play out in the -mm tree;
we'll see.)
- Ted
P.S. Yes, the currently released e2fsprogs won't support all of these
format changes yet; again ext4, shouldn't be deployed to production
systems yet, although we do salute those who are willing to be guinea
pigs and play with this code! Never fear, I'll be working to get
e2fsprogs caught up Real Soon Now.
Adrian Bunk (1):
ext4/super.c: fix #ifdef's (CONFIG_EXT4_* -> CONFIG_EXT4DEV_*)
Alex Tomas (2):
ext4: Add new functions for searching extent tree
ext4: Add multi block allocator for ext4
Aneesh Kumar K.V (23):
ext4: Introduce ext4_lblk_t
ext4: Introduce ext4_update_*_feature
ext4: Fix sparse warnings.
ext4: Rename i_file_acl to i_file_acl_lo
ext4: Rename i_dir_acl to i_size_high
ext4: Add support for 48 bit inode i_blocks.
ext4: Support large files
ext2: Fix the max file size for ext2 file system.
ext3: Fix the max file size for ext3 file system.
ext4: Return after ext4_error in case of failures
ext4: Change the default behaviour on error
Add buffer head related helper functions
ext4: add block bitmap validation
ext4: Check for the correct error return from
ext4: Make ext4_get_blocks_wrap take the truncate_mutex early.
ext4: Convert truncate_mutex to read write semaphore.
ext4: Take read lock during overwrite case.
ext4: Add EXT4_IOC_MIGRATE ioctl
ext4: Fix ext4_show_options to show the correct mount options.
ext4: Add ext4_find_next_bit()
ext4: Enable the multiblock allocator by default
ext4: Check for return value from sb_set_blocksize
ext4: Use the ext4_ext_actual_len() helper function
Avantika Mathur (2):
ext4: add ext4_group_t, and change all group variables to this type.
ext4: fixes block group number being set to a negative value
Chris Snook (1):
jbd2: Remove printk from J_ASSERT to preserve registers during BUG
Coly Li (1):
ext4: sync up block group descriptor with e2fsprogs.
Dmitry Monakhov (1):
ext4: fix uniniatilized extent splitting error
Eric Sandeen (6):
ext4 extents: remove unneeded casts
ext4: different maxbytes functions for bitmap & extent files
ext4: export iov_shorten from kernel for ext4's use
ext4: store maxbytes for bitmapped files and return EFBIG as appropriate
ext4: fix oops on corrupted ext4 mount
ext4: fix up EXT4FS_DEBUG builds
Girish Shilamkar (1):
ext4: Add the journal checksum feature
Jan Kara (2):
ext4: Avoid rec_len overflow with 64KB block size
jbd2: Fix assertion failure in fs/jbd2/checkpoint.c
Jean Noel Cordenner (2):
vfs: Add 64 bit i_version support
ext4: Add inode version support in ext4
Johann Lombardi (1):
jbd2: jbd2 stats through procfs
Mariusz Kozlowski (1):
ext4: remove unused code from ext4_find_entry()
Mingming Cao (4):
jbd2: add lockdep support
jbd2: Mark jbd2 slabs as SLAB_TEMPORARY
jbd2: Use round-jiffies() function for the "5 second" ext4/jbd2 wakeup
jbd2: sparse pointer use of zero as null
Takashi Sato (1):
ext4: Support large blocksize up to PAGESIZE
--
Wikipedia
http://en.wikipedia.org/wiki/Ext4
deleted file recovery
I would just like to enquire as to whether or not ext4 will allow easier recovery of files that have been deleted. Unfortunately my family has a habit of deleting things they need. Unfortunately I have read that it is very difficult to recover deleted files from an ext3 partition and I think resolving this issue in ext4 would be a great improvement particularly considering the ongoing move into the desktop and perhaps even the mobile markets.
quote: With Ext3, there is an additional step that makes recovery much more difficult. When the blocks are unallocated, the file size and block addresses in the inode are cleared; therefore we can no longer determine where the file content was located. http://linux.sys-con.com/read/117909.htm
Thanks for any info.
re: deleted file recovery
The proper solution to your family's habit is to use a userspace "Trash Can" / "Recycle Bin" system, where deleted files are not actually deleted, but instead moved to a designated folder on the KDE / GNOME desktop. If your family typically does file management from a GUI (and users who make this error repeatedly typically do), then it should be possible to activate this feature through a simple configuration choice in the Nautilus or Konqueror file manager.
"Trash Can" / "Recycle Bin"
That has always worked for me, when working it's playing it safe and with kids around the computer it's a must.
re:deleted file recovery
Hi im the original anonymous user.
Thanks for your response, and yeah my family does indeed use the GUI for file management but they often don't realise they needed a file until it is too late and they have either deleted the file via shift+delete which bypasses the trash (something i now regret showing them in windows) or emptying the trash. I understand that this SHOULDN'T be a concern and users shouldn't be deleting files they need but it DOES happen on occasion and more users means that it will happen more regularly. Unfortunately people who have done this on windows are used to being able to recover deleted files even from a formatted drive! and like my parents expected that I would be able to recover them as well something I would like to be able to do. So my question still stands, is ext4 still going to make it difficult to recover deleted files?
From the sounds of it, yes
It sounds to me like btrfs with its infinite snapshotting is much more in line with your needs than ext4. If anything it sounds like ext4 might make it harder to recover deleted files unless they add specific features for this. For example, it could park all deleted inodes in some disk-wide LRU to defer the delete until some threshold is met or the space is needed.
I know people have experimented with such schemes in the past, but they never seem to get much traction for kernel inclusion. The mantra has always been "do it in userspace." Such schemes have privacy issues, namespace issues, and so on. (Take a look at the date on that post... that's over 10 years ago.) And none of them address what happens when people get in the habit of skipping the "wastebasket" or start compulsively emptying it.
Me? I almost never delete anything. :-) It can make finding things a little challenging at times, though.
--
Program Intellivision and play Space Patrol!
Backup
Hello there. I am a system admin, and I have a lot of users who also delete files they find out they need later.
The only effective way to protect yourself from deleted files is to have another disk about the same size as your home partition, and use rsync and cron to replicate the user disk to the backup disk.
This method is file system independent, and does not impose speed penalties on the user disks.
"Google approach"
That is really not a kernel/filesystem issue. But I do think that file managers have very bad UI for file deletion/undeletion.
I think Google's way should be followed. As in GMail/Google Docs/..., files should be "archivable", so they don't clutter the usual folders but can still be found by search. And then the trash should have no easy option to empty it, but should delete stuff that has been in it for very long automatically...
I wasn't really asking for a
I wasn't really asking for a feature to store deleted files but rather whether the clearing of the the file size and block addresses in the inode would still be the the case as the article i read suggested that this is the reason for recovering deleted files is so difficult. I don't know enough about filesystems to know whether this is required but obviously other fs'es are doing something different.
I don't want special reservation of space/data for deleted files but if it's possible to avoid making recovery so difficult I think that would be a positive thing, if the data has been overwritten then its gone but if its still on disk I would like to be able to recover as with other filesystems.
btrfs
Well, when it becomes available, you might give serious thought to a filesystem like btrfs. The fact you can undelete files somewhat easily on a FAT filesystem is a happy accident, not a design decision. It's also not terribly reliable for files larger than one cluster. If you want a feature like that to be even remotely reliable, it really needs to be built into the FS.
If I'm not mistaken (and I may very well be), btrfs and its snapshot facility lets you roll back FS changes, including deletes. If that's the case, then that's your filesystem.
--
Program Intellivision and play Space Patrol!