Hello,
On Fri, May 15, 2009 at 9:58 PM, wrote:
> On Tue, Apr 28, 2009 at 09:47:58PM +0300, Sergiu Ivanov wrote:
>> I see... Although I'm familiar with your position as to the power of
>> the user over his software, I cannot really understand what ``enough
>> rope'' philosophy means... I've googl
Hi,
On Sat, May 02, 2009 at 08:16:32PM +0200, Carl Fredrik Hammar wrote:
> On Sun, Apr 26, 2009 at 06:28:51AM +0200, olafbuddenha...@gmx.net
> wrote:
> > On Thu, Apr 09, 2009 at 10:09:04PM +0200, Carl Fredrik Hammar wrote:
> > I do not see much point in mounting several file systems at the same
>
Hi,
On Mon, Apr 27, 2009 at 09:40:58PM +0300, Sergiu Ivanov wrote:
> for instance, unionfs is still read-only;
Really? I thought Gianluca worked on write support at some point...
Perhaps he never commited his changes :-(
-antrik-
Hi,
On Tue, Apr 28, 2009 at 09:47:58PM +0300, Sergiu Ivanov wrote:
> writes:
> > Even if you had found examples of translators that really don't seem
> > to make any sense being union-mounted (which seems quite probable
> > actually), I still think it should not be up to the translators to
> > d
Hi,
On Sun, Apr 26, 2009 at 10:48:13PM +0200, olafbuddenha...@gmx.net wrote:
> On Sat, Apr 11, 2009 at 03:03:45PM +0200, Carl Fredrik Hammar wrote:
> > On Fri, Apr 10, 2009 at 08:35:07PM +0300, Sergiu Ivanov wrote:
>
> > > Also, I'm not aware of anybody still doing any changes to unionfs
> > > :-
Hello,
On Sun, Apr 26, 2009 at 06:28:51AM +0200, olafbuddenha...@gmx.net wrote:
> On Thu, Apr 09, 2009 at 10:09:04PM +0200, Carl Fredrik Hammar wrote:
> > On Wed, Apr 08, 2009 at 07:10:26PM +0200, olafbuddenha...@gmx.net
> > wrote:
>
> > > while unionfs must be able to handle an arbitrary number
Hello,
writes:
> On Thu, Apr 09, 2009 at 10:03:27PM +0300, Sergiu Ivanov wrote:
>> writes:
>> > On Mon, Apr 06, 2009 at 04:26:25PM +0300, Sergiu Ivanov wrote:
>
>> >> This approach will require adding some user-modifiable flag to the
>> >> corresponding translator library that will allow to swit
Hello,
writes:
> On Fri, Apr 10, 2009 at 08:51:03PM +0300, Sergiu Ivanov wrote:
>> writes:
>> > On Wed, Apr 08, 2009 at 08:17:30PM +0300, Sergiu Ivanov wrote:
>
>> >> You see, I suppose that some time later we will be adding some
>> >> specific merging rules, which would be very difficult (if no
Hello,
writes:
> On Fri, Apr 10, 2009 at 08:35:07PM +0300, Sergiu Ivanov wrote:
>> Carl Fredrik Hammar writes:
>
>> > Well it isn't simpler in the sense that we'd need to maintain two
>> > very similar yet different code bases. Improvements to one would
>> > likely get ported to the other.
> [.
Hello,
writes:
> On Mon, Apr 06, 2009 at 04:26:25PM +0300, Sergiu Ivanov wrote:
>> OTOH, implementing unionmount as extensions to translator libraries
>> would mean faster operation and automatic inclusion of the
>> functionality in *every* existing translators, but modifying something
>> would r
Hi,
On Thu, Apr 09, 2009 at 07:29:27PM +0200, Carl Fredrik Hammar wrote:
> On Tue, Apr 07, 2009 at 12:20:40AM +0300, Sergiu Ivanov wrote:
> > This would yield faster code (no extra context switch, the shadow
> > node is within the main translator) and more control over the
> > merging functionali
Hi,
On Thu, Apr 09, 2009 at 10:03:27PM +0300, Sergiu Ivanov wrote:
> writes:
> > On Mon, Apr 06, 2009 at 04:26:25PM +0300, Sergiu Ivanov wrote:
> >> This approach will require adding some user-modifiable flag to the
> >> corresponding translator library that will allow to switch on and
> >> off
Hi,
On Fri, Apr 10, 2009 at 08:51:03PM +0300, Sergiu Ivanov wrote:
> writes:
> > On Wed, Apr 08, 2009 at 08:17:30PM +0300, Sergiu Ivanov wrote:
> >> You see, I suppose that some time later we will be adding some
> >> specific merging rules, which would be very difficult (if not
> >> impossible)
Hi,
On Thu, Apr 09, 2009 at 08:08:58PM +0200, Carl Fredrik Hammar wrote:
> > > unionmount is expected to merge the filesystem on which it sits
> > > with the filesystem exposed by the translator it is asked to start
> > > in unionmount mode (further referred to as ``the Translator'').
> >
> > Na
Hi,
On Sat, Apr 11, 2009 at 03:03:45PM +0200, Carl Fredrik Hammar wrote:
> On Fri, Apr 10, 2009 at 08:35:07PM +0300, Sergiu Ivanov wrote:
> > Also, I'm not aware of anybody still doing any changes to unionfs
> > :-)
[...]
> Also, in many ways unionfs seems like an good candidate to make use of
>
Hi,
On Fri, Apr 10, 2009 at 08:35:07PM +0300, Sergiu Ivanov wrote:
> Carl Fredrik Hammar writes:
> > Well it isn't simpler in the sense that we'd need to maintain two
> > very similar yet different code bases. Improvements to one would
> > likely get ported to the other.
[...]
> Also, I'm not a
Hi,
On Fri, Apr 10, 2009 at 07:29:43PM +0300, Sergiu Ivanov wrote:
> writes:
> >settrans veth /hurd/unionfs veth veth,,eth-multiplexer
>
> unionfs has option ``-u'' which tells it to include the underlying
> node in the list of the merged filesystems, so this command should be
> rewritten l
Hi,
On Thu, Apr 09, 2009 at 10:09:04PM +0200, Carl Fredrik Hammar wrote:
> On Wed, Apr 08, 2009 at 07:10:26PM +0200, olafbuddenha...@gmx.net
> wrote:
> > while unionfs must be able to handle an arbitrary number of merged
> > locations, for unionmount it's always exactly two. This simplifies
> > t
Hi!
On Mon, Apr 13, 2009 at 12:41:07AM +0300, Sergiu Ivanov wrote:
> [snip]
>
> >> This is true that in the greater part of the operation of unionmount
> >> there will be no difference in speed (the difference will be at startup,
> >> of course). However, I still don't have sufficiently compelling
Hello,
Da Zheng writes:
> Carl Fredrik Hammar wrote:
>>> It is not fully clear right now -- I realized that there is another
>>> decision to make: should the unionmount translator be directly visible
>>> as the translator attached to the mount node; or should it serve as a
>>> proxy, forwarding a
Hi,
Carl Fredrik Hammar wrote:
It is not fully clear right now -- I realized that there is another
decision to make: should the unionmount translator be directly visible
as the translator attached to the mount node; or should it serve as a
proxy, forwarding all requests on the filesystem port to
Hello,
Carl Fredrik Hammar writes:
> On Fri, Apr 10, 2009 at 08:35:07PM +0300, Sergiu Ivanov wrote:
>> Anyway, I'm not sure whether bringing some details in the code in
>> unionmount up to date will require ``porting'', since I'm going to touch
>> only a very small portion of the code, leaving th
Hello,
On Fri, Apr 10, 2009 at 08:35:07PM +0300, Sergiu Ivanov wrote:
> Carl Fredrik Hammar writes:
> > On Tue, Apr 07, 2009 at 12:20:40AM +0300, Sergiu Ivanov wrote:
> >> > [...]
> >> > If you're uncomfortable keeping around a process just to implement
> >> > a shadow node, consider implementing
writes:
> On Wed, Apr 08, 2009 at 08:17:30PM +0300, Sergiu Ivanov wrote:
>
>> You see, I suppose that some time later we will be adding some
>> specific merging rules, which would be very difficult (if not
>> impossible) with the approach you are suggesting (about reusing
>> unionfs as a whole).
>
Carl Fredrik Hammar writes:
> On Tue, Apr 07, 2009 at 12:20:40AM +0300, Sergiu Ivanov wrote:
>> > [...]
>> > If you're uncomfortable keeping around a process just to implement
>> > a shadow node, consider implementing a dedicated shadow node server.
>> > That just sitts on e.g. `/server/shadow' an
On Fri, Apr 10, 2009 at 07:18:34PM +0300, Sergiu Ivanov wrote:
> Carl Fredrik Hammar writes:
> >> I actually realized a couple of days ago that unionmount could probably
> >> be done by a combination of nsmux and unionfs: I think it should be
> >> possible to do something like
> >>
> >>settra
writes:
> I actually realized a couple of days ago that unionmount could probably
> be done by a combination of nsmux and unionfs: I think it should be
> possible to do something like
>
>settrans veth /hurd/unionfs veth veth,,eth-multiplexer
unionfs has option ``-u'' which tells it to include
Carl Fredrik Hammar writes:
>> I actually realized a couple of days ago that unionmount could probably
>> be done by a combination of nsmux and unionfs: I think it should be
>> possible to do something like
>>
>>settrans veth /hurd/unionfs veth veth,,eth-multiplexer
>>
>> (I didn't want to b
Hi,
On Wed, Apr 08, 2009 at 08:17:30PM +0300, Sergiu Ivanov wrote:
> You see, I suppose that some time later we will be adding some
> specific merging rules, which would be very difficult (if not
> impossible) with the approach you are suggesting (about reusing
> unionfs as a whole).
On the cont
Hi,
On Wed, Apr 08, 2009 at 07:10:26PM +0200, olafbuddenha...@gmx.net wrote:
> On Mon, Apr 06, 2009 at 06:58:23PM +0200, Carl Fredrik Hammar wrote:
> > On Mon, Apr 06, 2009 at 04:26:25PM +0300, Sergiu Ivanov wrote:
>
> > So the only difference between unionmount and unionfs is the setup and
> > t
Hi,
> > unionmount is expected to merge the filesystem on which it sits with
> > the filesystem exposed by the translator it is asked to start in
> > unionmount mode (further referred to as ``the Translator'').
>
> Nah, I think there are various clearer ways to name it: e.g. "target
> translator"
Hi!
On Tue, Apr 07, 2009 at 12:20:40AM +0300, Sergiu Ivanov wrote:
> > Then it might be possible to implement the shadow node in unionmount
> > and pass it to unionfs. Just wrap a file descriptor around the port
> > and let unionfs inherit it, to make unionfs use it pass `/dev/fd/$FD'
> > as an a
Hi,
On Mon, Apr 06, 2009 at 06:58:23PM +0200, Carl Fredrik Hammar wrote:
> On Mon, Apr 06, 2009 at 04:26:25PM +0300, Sergiu Ivanov wrote:
> So the only difference between unionmount and unionfs is the setup and
> the shadow node, right?
Well, not quite. unionmount needs additional functionality
Hi,
On Mon, Apr 06, 2009 at 04:26:25PM +0300, Sergiu Ivanov wrote:
> OTOH, implementing unionmount as extensions to translator libraries
> would mean faster operation and automatic inclusion of the
> functionality in *every* existing translators, but modifying something
> would require more effor
Hello,
Carl Fredrik Hammar writes:
> On Mon, Apr 06, 2009 at 04:26:25PM +0300, Sergiu Ivanov wrote:
>> I would like to start a discussion about some basic details
>> implementation of the unionmount project.
>>
>> Firstly, the implementation was suggested in two ways: as a stand-alone
>> translat
Hi,
On Mon, Apr 06, 2009 at 04:26:25PM +0300, Sergiu Ivanov wrote:
> Hello,
>
> I would like to start a discussion about some basic details
> implementation of the unionmount project.
>
> Firstly, the implementation was suggested in two ways: as a stand-alone
> translator and as a series of exten
Hello,
I would like to start a discussion about some basic details
implementation of the unionmount project.
Firstly, the implementation was suggested in two ways: as a stand-alone
translator and as a series of extensions to lib{net,disk}fs
libraries. These two approaches have there advantages an
37 matches
Mail list logo
