Jack Schwartz wrote: > Hi Jan SE. > > Thanks for confirming that you didn't see the update limitation as a bug. > > We'll go with that for now. ... and I'll just ask the question: if we > filed a bug to get dcfs update working, what are the chances this > enhancement could be made?
Low. Figuring out how to make zfs a viable solution for small compressed filesystems seems like a much more likely approach. -jan > Thanks, > Jack > > On 12/18/08 14:25, Jan Setje-Eilers wrote: >> jan damborsky wrote: >>> Hi Jack, >>> >>> >>> Jack Schwartz wrote: >>>> When I spoke yesterday to Jan Setje-eilers I wasn't under the >>>> impression that he thought this was a dcfs bug to be fixed. Being >>>> that each file is compressed individually, he said just don't >>>> compress the files which will be needed for update. >>> >>> To be honest, I am not sure if this is the good long term approach >>> to deal with this dcfs(7F) limitation. >>> >>> As we found out hitting this problem can generate issues which >>> are not quite obvious they are caused by dcfs(7F) and thus might >>> be not quite straightforward to evaluate/debug. >>> >>> Apparently, we can't always determine in advance which files need >>> to be put on the list until we hit the problem which is manifestation >>> of not having particular file on the list containing entries which >>> are not compressed. >>> >>> I agree with you that this can be considered rather enhancement >>> giving the fact that dcfs(7F) was initially considered to be used >>> in read-only mode (for legacy miniroot), but since microroot is >>> writable, my feeling is it might be better solve that problem on >>> dcfs(7F) >>> level once, rather than maintain special list of files forever. >> >> This is not a bug in dcfs. dcfs fundamentally doesn't work that way. >> You're asking for seamlessly compressing ufs. I don't know of any >> plans to add such support to ufs (or any other feature to ufs) for >> that matter. >> >> -jan
