| |||||||||||||
Re: Pity userspace on where this is done on a simple minded filesystemRe: Pity userspace on where this is done on a simple minded filesystemPosted May 6, 2009 0:00 UTC (Wed) by daney (subscriber, #24551)In reply to: Pity userspace on where this is done on a simple minded filesystem by adj Parent article: The two sides of reflink()
On your filesystem that has 200Gbyte blocks you would indeed wait a while.
On my filesystem with somewhat smaller blocks presumably the wait would be shorter.
(Log in to post comments)
Re: Pity userspace on where this is done on a simple minded filesystem Posted May 6, 2009 0:12 UTC (Wed) by adj (subscriber, #7401) [Link]
Where does my filesystem get 200Gbyte blocks? Per the article, "a write to either file will cause some or all of the blocks to be duplicated." I have to think the bookkeeping involved in the former would be simpler and is more likely to be implemented as a prototype in a non-OCFS2 filesystem. At least in the short term.
Re: Pity userspace on where this is done on a simple minded filesystem Posted May 6, 2009 0:17 UTC (Wed) by adj (subscriber, #7401) [Link]
s/former/latter/ in the above.
Re: Pity userspace on where this is done on a simple minded filesystem Posted May 6, 2009 0:57 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] But appending (to logs, for example) is such a common special case that it would be likely to be supported at an early stage, so that you have an efficient representation when you take a snapshot of a filesystem, and then you let it go on, appending lots of stuff to your log files, blocks belonging to a common prefix can be shared.
Re: Pity userspace on where this is done on a simple minded filesystem Posted May 6, 2009 1:01 UTC (Wed) by corbet (editor, #1) [Link] btrfs, at least, has COW wired pretty deeply into it. So it will only copy blocks which have actually been changed. Results on other filesystems may vary.
|
|||||||||||||