Create an account

Subscribe to LWN

LWN.net Weekly Edition for May 23, 2013

An "enum" for Python 3

An unexpected perf feature

LWN.net Weekly Edition for May 16, 2013

A look at the PyPy 2.0 release

Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

Pity userspace on where this is done on a simple minded filesystem

Pity userspace on where this is done on a simple minded filesystem

Posted May 5, 2009 23:36 UTC (Tue) by adj (subscriber, #7401)
Parent article: The two sides of reflink()

reflink("myold200Gbytefile", "myreflinked20Gbytefile); myfd = open("myreflinked200Gbytefile", (O_WRONLY|O_APPEND|O_LARGEFILE)); res = write(myfd, "hereismyshortlittlemessage", 27); /* * wait, like _forever_ while i just added 200Gbytes to the amount * of space used on this filesystem. Not to mention getting back * ENOSPC, because, even though there were 100Gbytes available * before this 27 byte long write, now there are none. reflinks * sound neat, but sometimes have unexpected teeth. */

(Log in to post comments)

Re: Pity userspace on where this is done on a simple minded filesystem

Posted May 6, 2009 0:00 UTC (Wed) by daney (subscriber, #24551) [Link]

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.

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.

Pity userspace on where this is done on a simple minded filesystem

Posted May 6, 2009 18:49 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link]

Simple answer: Don't implement this on simple minded filesystems. :-) Save it for filesystems that COW effectively (Btrfs), or can be taught to do so (ext4). I doubt anyone's planning to implement this over xiafs or vfat.

Slightly fancier answer: Perhaps this is another thing to "ulimit"? Return EPERM or EFBIG (file is too big) if the limit's exceeded.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds