Re: question on new feature complexity/possibility/sensibility? (^ Alternate)

[Linda Walsh <xfs@tlinx.org>]

Dave Chinner wrote:
> So use a filesystem that supports them natively ;)
---
	Got any in in mind that also support acls, extended attrs
and has the reliability and performance of xfs?  ;-)
> 
>> I.e. being able to hardlink files, but have an option to mark it as
>> copy on write -- allowing space to be save when copying directory trees,
>> but then dynamically making new copies when someone updates one of the
>> linked copies.
> 
> The problem is that a reflink sort of looks like a hard link, but in
> many cases behaves like a soft link (e.g. different owners,
> permissions, etc are possible) and hence - combined with the
> copy-on-write behaviour - they need to be treated more like a
> soft-link in terms of implementation.
----
	I can see this -- now this doesn't mean we are talking the same
type of reflink with the shared data above is it?  Cuz in this lower
case, I was talking about hmmm....interesting....

	I was thinking of just a copy-of-the whole file on write,
but that'd be a potential pain on some systems depending on the file
size....   

> Soft links have their own
> inode so can hold state separate to the inode they are pointing to,
> and for reflinked files it is simply not practical to retroactively
> modify the directory structure to point at a different inode when
> the first COW operation occurs.
----
	I see....   
> 
> Like I said, it can be done, but it's not a small project. If you
> want to sink a significant amount of development time to the
> project, we will help you in any way we can. However, I don't think
> anyone has the time to do something like this for you....
---
	If I had the time and mental resources...I'd love to.
But am a bit overwhelmed for time now, and even if I wasn't, I'd
not be anywhere near certain I'd be able to maintain continuous focus
for the length of time necessary to do that length of project....  
if you know what I mean...

	Maybe certain if it was something that I or others could break
down into useful 'subchunks' that could go in at separate times.  Nothing
useless by itself (if nothing less than specific 'upgrading' of 
data infrastructure (data fields on disk, routines to parse such...etc),
but the whole thing at once seems pretty large.

(I know...I'm being a wimp)...

to support such things in the future


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs