lkml.org 
[lkml]   [2003]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ReiserFS patch for updating ctimes of renamed files
jw schultz wrote:

>On Sun, Oct 12, 2003 at 01:05:19AM -0500, Alex Adriaanse wrote:
>
>
>>Hi,
>>
>>I ran into some trouble trying to do incremental backups with GNU tar
>>(using --listed-incremental) where renaming a file in between backups would
>>cause the file to disappear upon restoration. When investigating the issue
>>I discovered that this doesn't happen on ext2, ext3, and tmpfs filesystems
>>but only on ReiserFS filesystems. I also noticed that for example ext3
>>updates the affected file's ctime upon rename whereas ReiserFS doesn't, so
>>I'm thinking this causes tar to believe that the file existed before the
>>first backup was taking under the new name, and as a result it doesn't back
>>it up during the second backup. So I believe ReiserFS needs to update
>>ctimes for renamed files in order for incremental GNU tar backups to work
>>reliably.
>>
>>I made some changes to the reiserfs_rename function that I *think* should
>>fix the problem. However, I don't know much about ReiserFS's internals, and
>>I haven't been able to test them out to see if things work now since I can't
>>afford to deal with potential FS corruption with my current Linux box.
>>
>>I included a patch below against the 2.4.22 kernel with my changes. Would
>>somebody mind taking a look at this to see if I did things right here (and
>>perhaps wouldn't mind testing it out either)? If it works then I (and I'm
>>sure others who've experienced the same problem) would like to see the
>>changes applied to the next 2.4.x (and 2.6.x?) release.
>>
>>
>
>Hmm. I'm conflicted.
>
>rename(2) manpage:
> Any other hard links to the file (as created using
> link(2)) are unaffected.
>
>A change to ctime would affect the other links.
>
>stat(2) manpage:
> The field st_ctime is changed by writing or by
> setting inode information (i.e., owner, group, link
> count, mode, etc.).
>
>I am not aware of any field in the inode structure that must
>be changed by an atomic rename. Per documentation the only
>reason rename should update st_ctime is if it does a
>link+unlink sequence which would alter st_nlink briefly.
>
>On the other hand it does seem to me there ought to be some
>record that something about the inode changed. st_ctime would
>be the only appropriate indicator.
>
>rename() SUSv3:
> Some implementations mark for update the st_ctime
> field of renamed files and some do not. Applications
> which make use of the st_ctime field may behave
> differently with respect to renamed files unless
> they are designed to allow for either behavior.
>
>So reiserfs is on this point definitely standards conformant
>already. A change could at best be seen as an enhancement.
>
>
>
>
>
>
thanks Mr. Schultz, you saved us a lot of work in reviewing this issue.

In theory it is cleaner and purer to do it the way we did. In practice,
Alex's problem seems like a real one, and I don't know how hard it is to
change tar to do the right thing. We'll discuss it in a small seminar
today.

--
Hans


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.169 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site