hooanon05@xxxxxxxxxxx writes:
> Goswin von Brederlow:
>> hooanon05@xxxxxxxxxxx writes:
> ::
>> > When a user writes something to the file after unlink+rmdir, where can
>> > deltafs copyup? At least in the current implementation, there is no
>> > place for it.
> :::
>> In the delta branch create a meta/ and files/ directory. In the meta/
>> directory you keep whiteout files and stat updates. In files/ you
>> store only changes in the file data itself.
>>
>> So "rm foo/bar/baz" will create meta/foo/bar/baz.whiteout. Then "echo
>> blafase >>foo/bar/baz" first searches for a file to copy-up, sees the
>> meta/foo/bar/baz.whiteout and knows the file was deleted. It then
>> creates a new files/foo/bar/baz. It might have to copy-up foo and
>> foo/bar for that though.
>
> ??
> What I am pointing out is systemcall level operation instead of command
> level.
> In your example (or implementation approach), can deltafs successfully
> operate "write(2) to and read(2) from foo/bar/baz" after "rm -r foo/bar"?
>
> (from my previous mail)
> ----------------------------------------------------------------------
> - open a file on deltafs
> - unlink it
> - rmdir its parent
> - write or fchmod to it
> - rewind+read or mmap+read from the opened file
> - cat it be read correctly?
> ----------------------------------------------------------------------
>
>
> J. R. Okajima
As I said, keep the FDs open. In case of the split meta/files dirs you
would have orig_fd, meta_fd and delta_fd. And make read/write operate
on fi->fh only, not the path to the file. That way the delta-fs will
operate like any other userspace program doing read/write after an
unlink.
MfG
Goswin
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
