From mboxrd@z Thu Jan 1 00:00:00 1970 From: cwillu Subject: Re: hard links across snapshots/subvolumes are actually a bad idea. Date: Wed, 24 Nov 2010 17:57:26 -0600 Message-ID: References: <4CED9FCC.9080804@bobich.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: BTRFS MAILING LIST To: unlisted-recipients:; (no To-header on input) Return-path: In-Reply-To: <4CED9FCC.9080804@bobich.net> List-ID: On Wed, Nov 24, 2010 at 5:29 PM, Gordan Bobic wrote: > On 11/24/2010 10:07 PM, David Nicol wrote: >> >> I've been thinking about this for a while, from a perspective of how >> to make it work by allocating i-node numbers from a global pool, but >> yesterday I realized that offering the feature would be a bad idea >> because it violates the semantics of file systems. >> >> I will be happy to expand on that point if anyone disagrees with it. > > One thing I would like to see is copy-on-write hard-links. The hard-links > that span snapshots should be possible, but they should be copy-on-write, > i.e. as soon as hard-linked file that spans snapshots is written, the > snapshot that wrote it should have it's own forked copy henceforth. There are sym-links, hard-links, and ref-links. Cross device symlinks are trivial. Cross device hardlinks are evil. Cross device ref-links are just plain smart (and are at least partitially implemented in btrfs; does bcp work across subvolumes?). :)