Re: Starting a grad project that may change kernel VFS. Early research Re: Starting a grad project that may change kernel VFS. Early research

[Bryan Donlan]

On Wed, Aug 26, 2009 at 10:42 AM, Jeff Shanab<jshanab@xxxxxxxxxxxxx> wrote:

> Admittedly I need to study up on how recovery works now, especially for
> a journaled file system.
>
> Perhaps there is a 3. A sort of Distributed write Ahead log stored in
> the inode of the directory itself.
> If the process is completed, it is removed adding a second write to the
> dentry's inode. If not, the queued task is found during fsck and started
> again. But this fails if the changes to an dentry's inode are just
> sitting in the cache at time of crash. Is the journal a write through
> cache system? Is there a reference you can recommend?, I have just been
> googeling and reading some source code.

With journalling filesystems, fsck will not be run in a crash, so a
flag as you suggest is insufficient. Moreover, a fsck will traverse
the entire filesystem, so it can (and must) just directly check that
all size fields are correct.

In a typical journalling filesystem such as ext3, prior to making any
changes to the disk, it will write a copy of all changes it will make
to a seperate log. Once these are committed to disk, they will be
copied to their final locations in the real filesystem data and
metadata. Other filesystems such as btrfs use the 'dancing trees'
approach - where the new data is allocated into free space, and commit
is done by changing some root pointers to make this new data be used.

You may want to take a look at
http://olstrans.sourceforge.net/release/OLS2000-ext3/OLS2000-ext3.html
for an overview of how ext3 in particular works.

>>
>> As far as knowing whether or not a copy will succeed, that depends on
>> whether the copy is going to be smart about preseving hard links, and
>> whether or not the copy will be copying symlinked files as real files.
>> So you can only give a very specialized answer assuming only one set
>> of copy options.
>>
>>                                               - Ted
>>
>>
> I have a seemingly dumb question, but I need a good answer for it. What
> good are hardlinks, Do we need them with the advent of symlinks? Are
> they just a vestigial feature or is there a real use case where they are
> preferred? I don't think I have any hard links on this machine, but of
> course, how would I know? ;-) I know i have seen them used in some
> chroot environments at work.

Run: find / -xdev -type f -and -not -links 1

A typical debian installation contains a number of hardlinks,
including some for identical timezones under different names, or for
wine's wrapper scripts, or for gunzip and uncompress, or for various
e2fstools, or many other examples.

> I can see they allow du, for example, to give an accurate size of a
> directory as it would be if copied to another drive, symlinks don't do
> that AFAIK. In fact the copy is missing data. Guess I answered My own
> question?

I have no idea what you mean by this...
Keep in mind du can dereference symlinks to get the size of the target
(-L option).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/