ve to come up with something in the way of a
> modern storage subsystem.
>
> > -Original Message-
> > From: Andrzej Bialecki [SMTP:[EMAIL PROTECTED]]
> > Sent: Saturday, October 30, 1999 10:56 AM
> > To: Alton, Matthew
> > Subject: Re: BSD XFS Port
: Andrzej Bialecki [SMTP:[EMAIL PROTECTED]]
> Sent: Saturday, October 30, 1999 10:56 AM
> To: Alton, Matthew
> Subject: Re: BSD XFS Port & BSD VFS Rewrite
>
> On Thu, 5 Aug 1999, Alton, Matthew wrote:
>
> > I am currently conducting a thorough study of the VFS subsy
In message <[EMAIL PROTECTED]>, Terry Lambert writes:
>> >You would have to de-collapse several VOP lists that have been
>> >pre-collapsed.
>>
>> You are talking gibberish here. Please show code where this is
>> a problem.
>
>When you write a proxy stacking layer, such as John Heidemann's
>netw
On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
> Yes, but we need subsecond in the filesystems. Think about make(1) on
> a blinding fast machine...
Oh yes, I realize that. :-) It's just that I thought you were at one point
suggesting having 128 bits to the left of the decimal point (128 bits
wort
In message <199908181737.laa03...@mt.sri.com>, Nate Williams writes:
>> > Both struct timespec and struct timeval are major mistakes, they
>> > make arithmetic on timestamps an expensive operation. Timestamps
>> > should be stored as integers using an fix-point notations, for
>> > instance 64bits
> >> > > I'm not familiar with the VFS_default stuff. All the vop_default_desc
> >> > > routines in NetBSD point to error routines.
> >> >
> >> > In FreeBSD, they now point to default routines that are *not* error
> >> > routines. This is the problem. I admit the change was very well
> >> > inte
On Wed, 18 Aug 1999, Terry Lambert wrote:
> > Right. That exported struct lock * makes locking down to the lowest-level
> > file easy - you just feed it to the lock manager, and you're locking the
> > same lock the lowest level fs uses. You then lock all vnodes stacked over
> > this one at the sam
In message <199908181848.laa14...@usr02.primenet.com>, Terry Lambert writes:
>> >You would have to de-collapse several VOP lists that have been
>> >pre-collapsed.
>>
>> You are talking gibberish here. Please show code where this is
>> a problem.
>
>When you write a proxy stacking layer, such as
The discussions between Kirk and matt over a glass of beer/drink
at kirk's party at USENIX and at the Bay area User's group.
On Wed, 18 Aug 1999, Nate Williams wrote:
> > > Matt doesn't represent the FreeBSD project, and even if he rewrites
> > > the VFS subsystem so he can understand it, his r
:On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
:
:> Matt doesn't represent the FreeBSD project, and even if he rewrites
:> the VFS subsystem so he can understand it, his rewrite would face
:> considerable resistance on its way into FreeBSD. I don't think
:> there is reason to rewrite it, but there
> > Matt doesn't represent the FreeBSD project, and even if he rewrites
> > the VFS subsystem so he can understand it, his rewrite would face
> > considerable resistance on its way into FreeBSD. I don't think
> > there is reason to rewrite it, but there certainly are areas
> > that need fixing.
>
On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
> Matt doesn't represent the FreeBSD project, and even if he rewrites
> the VFS subsystem so he can understand it, his rewrite would face
> considerable resistance on its way into FreeBSD. I don't think
> there is reason to rewrite it, but there cer
> > > > > > 2. Advisory locks are hung off private backing objects.
> > > I'm not sure. The struct lock * is only used by layered filesystems, so
> > > they can keep track both of the underlying vnode lock, and if needed their
> > > own vnode lock. For advisory locks, would we want to keep track b
In message , Bill
Studenmund writes:
>> >I doubt we need more than 64 bit times. 2^63 seconds works out to
>> >292,279,025,208 years, or 292 (american) billion years. Current theories
>> >put the age of the universe at I think 12 to 16 billion years. So 64-bit
>> >signed times in seconds will cov
In message ,
Julian Elischer writes:
>On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
>
>> Matt doesn't represent the FreeBSD project, and even if he rewrites
>> the VFS subsystem so he can understand it, his rewrite would face
>> considerable resistance on its way into FreeBSD. I don't think
>> th
> >> > > I'm not familiar with the VFS_default stuff. All the vop_default_desc
> >> > > routines in NetBSD point to error routines.
> >> >
> >> > In FreeBSD, they now point to default routines that are *not* error
> >> > routines. This is the problem. I admit the change was very well
> >> > int
On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
> Yes, but we need subsecond in the filesystems. Think about make(1) on
> a blinding fast machine...
Oh yes, I realize that. :-) It's just that I thought you were at one point
suggesting having 128 bits to the left of the decimal point (128 bits
wor
On Wed, 18 Aug 1999, Terry Lambert wrote:
> > Right. That exported struct lock * makes locking down to the lowest-level
> > file easy - you just feed it to the lock manager, and you're locking the
> > same lock the lowest level fs uses. You then lock all vnodes stacked over
> > this one at the sa
In message <[EMAIL PROTECTED]>, Nate Williams writes:
>> > Both struct timespec and struct timeval are major mistakes, they
>> > make arithmetic on timestamps an expensive operation. Timestamps
>> > should be stored as integers using an fix-point notations, for
>> > instance 64bits with 32bit fra
On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
> Matt doesn't represent the FreeBSD project, and even if he rewrites
> the VFS subsystem so he can understand it, his rewrite would face
> considerable resistance on its way into FreeBSD. I don't think
> there is reason to rewrite it, but there ce
The discussions between Kirk and matt over a glass of beer/drink
at kirk's party at USENIX and at the Bay area User's group.
On Wed, 18 Aug 1999, Nate Williams wrote:
> > > Matt doesn't represent the FreeBSD project, and even if he rewrites
> > > the VFS subsystem so he can understand it, his
> > Matt doesn't represent the FreeBSD project, and even if he rewrites
> > the VFS subsystem so he can understand it, his rewrite would face
> > considerable resistance on its way into FreeBSD. I don't think
> > there is reason to rewrite it, but there certainly are areas
> > that need fixing.
>
> > > > > > 2. Advisory locks are hung off private backing objects.
> > > I'm not sure. The struct lock * is only used by layered filesystems, so
> > > they can keep track both of the underlying vnode lock, and if needed their
> > > own vnode lock. For advisory locks, would we want to keep track
:On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
:
:> Matt doesn't represent the FreeBSD project, and even if he rewrites
:> the VFS subsystem so he can understand it, his rewrite would face
:> considerable resistance on its way into FreeBSD. I don't think
:> there is reason to rewrite it, but ther
In message <[EMAIL PROTECTED]>, Julian
Elischer writes:
>On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
>
>> Matt doesn't represent the FreeBSD project, and even if he rewrites
>> the VFS subsystem so he can understand it, his rewrite would face
>> considerable resistance on its way into FreeBSD.
In message <[EMAIL PROTECTED]>, Bill
Studenmund writes:
>> >I doubt we need more than 64 bit times. 2^63 seconds works out to
>> >292,279,025,208 years, or 292 (american) billion years. Current theories
>> >put the age of the universe at I think 12 to 16 billion years. So 64-bit
>> >signed times
"Daniel C. Sobral" wrote:
>
> Terry Lambert wrote:
> >
> > That's kind of the point. No other VFS stacking system out there
> > plays by FreeBSD's revamped rules.
>
> I look around and I see no standards. It is still time to be
> experimental.
Since someone complained of my meekness, let me res
"Daniel C. Sobral" wrote:
>
> Terry Lambert wrote:
> >
> > That's kind of the point. No other VFS stacking system out there
> > plays by FreeBSD's revamped rules.
>
> I look around and I see no standards. It is still time to be
> experimental.
Since someone complained of my meekness, let me re
Terry Lambert wrote:
>
> That's kind of the point. No other VFS stacking system out there
> plays by FreeBSD's revamped rules.
I look around and I see no standards. It is still time to be
experimental.
--
Daniel C. Sobral(8-DCS)
d...@newsguy.com
d...@freebsd.org
Terry Lambert wrote:
>
> That's kind of the point. No other VFS stacking system out there
> plays by FreeBSD's revamped rules.
I look around and I see no standards. It is still time to be
experimental.
--
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
On Wed, Aug 18, 1999 at 08:43:14PM +, Terry Lambert wrote:
> > > > Nope. The problem is that while stacking (null, umap, and overlay fs's)
> > > > work, we don't have the coherency issues worked out so that upper layers
> > > > can cache data. i.e. so that the lower fs knows it has to ask the u
On Wed, Aug 18, 1999 at 08:43:14PM +, Terry Lambert wrote:
> > > > Nope. The problem is that while stacking (null, umap, and overlay fs's)
> > > > work, we don't have the coherency issues worked out so that upper layers
> > > > can cache data. i.e. so that the lower fs knows it has to ask the
On Thu, 19 Aug 1999, Alton, Matthew wrote:
> Do you have access to more of the code than is currently posted on SGI's
> web page? I am willing to sign an NDA in order to get access to all
> relevant source. I would like to assist in porting XFS to Linux also. I
> would
> very much like to see
On Thu, 19 Aug 1999, Alton, Matthew wrote:
> Do you have access to more of the code than is currently posted on SGI's
> web page? I am willing to sign an NDA in order to get access to all
> relevant source. I would like to assist in porting XFS to Linux also. I would
> very much like to see SG
> Terry Lambert wrote:
> >
> > Make sure that the system you are talking to over the proxy is
> > not assumed to be a FreeBSD system (e.g. don't assume that the
> > vfs_default stuff exists on the other end of the proxy, or that
> > it would be functional).
>
> Now, Terry, that is ridiculous. One
> Terry Lambert wrote:
> >
> > Make sure that the system you are talking to over the proxy is
> > not assumed to be a FreeBSD system (e.g. don't assume that the
> > vfs_default stuff exists on the other end of the proxy, or that
> > it would be functional).
>
> Now, Terry, that is ridiculous. On
Alton, Matthew
> Cc: 'hack...@freebsd.org'; 'f...@freebsd.org'
> Subject: Re: BSD XFS Port & BSD VFS Rewrite
>
> Glad to hear somebody is willing to dive in to XFS.
>
>
> Right now I am one of three people working on the XFS to linux port,
ton, Matthew
> Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
> Subject: Re: BSD XFS Port & BSD VFS Rewrite
>
> Glad to hear somebody is willing to dive in to XFS.
>
>
> Right now I am one of three people working on the XFS to linux port,
Glad to hear somebody is willing to dive in to XFS.
Right now I am one of three people working on the XFS to linux port, so I
have
pretty good view of what is currently happening.
When is it going to be ready?
Don't hold your breath. Officially SGI has said by the end of the year,
technically...
Glad to hear somebody is willing to dive in to XFS.
Right now I am one of three people working on the XFS to linux port, so I
have
pretty good view of what is currently happening.
When is it going to be ready?
Don't hold your breath. Officially SGI has said by the end of the year,
technically..
Terry Lambert wrote:
>
> Make sure that the system you are talking to over the proxy is
> not assumed to be a FreeBSD system (e.g. don't assume that the
> vfs_default stuff exists on the other end of the proxy, or that
> it would be functional).
Now, Terry, that is ridiculous. One has to assume t
Terry Lambert wrote:
>
> Make sure that the system you are talking to over the proxy is
> not assumed to be a FreeBSD system (e.g. don't assume that the
> vfs_default stuff exists on the other end of the proxy, or that
> it would be functional).
Now, Terry, that is ridiculous. One has to assume
> Terry,
>
> It is very fine with this example, but I'm not even going to bother
> much with it for several reasons, most of which you can find codified
> in the development rules for X11 which you can find in Scheiflers
> book.
>
> But for the record: your example would get even shorter on
> the
> Terry,
>
> It is very fine with this example, but I'm not even going to bother
> much with it for several reasons, most of which you can find codified
> in the development rules for X11 which you can find in Scheiflers
> book.
>
> But for the record: your example would get even shorter on
> th
Terry,
It is very fine with this example, but I'm not even going to bother
much with it for several reasons, most of which you can find codified
in the development rules for X11 which you can find in Scheiflers
book.
But for the record: your example would get even shorter on
the code we had befo
> >> >You would have to de-collapse several VOP lists that have been
> >> >pre-collapsed.
> >>
> >> You are talking gibberish here. Please show code where this is
> >> a problem.
> >
> >When you write a proxy stacking layer, such as John Heidemann's
> >network proxy stacking layer (an NFS altern
> >> >You would have to de-collapse several VOP lists that have been
> >> >pre-collapsed.
> >>
> >> You are talking gibberish here. Please show code where this is
> >> a problem.
> >
> >When you write a proxy stacking layer, such as John Heidemann's
> >network proxy stacking layer (an NFS alterna
> > > Right. That exported struct lock * makes locking down to the lowest-level
> > > file easy - you just feed it to the lock manager, and you're locking the
> > > same lock the lowest level fs uses. You then lock all vnodes stacked over
> > > this one at the same time. Otherwise, you just call VO
Terry,
It is very fine with this example, but I'm not even going to bother
much with it for several reasons, most of which you can find codified
in the development rules for X11 which you can find in Scheiflers
book.
But for the record: your example would get even shorter on
the code we had bef
> > > Right. That exported struct lock * makes locking down to the lowest-level
> > > file easy - you just feed it to the lock manager, and you're locking the
> > > same lock the lowest level fs uses. You then lock all vnodes stacked over
> > > this one at the same time. Otherwise, you just call V
On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
> Yes, but we need subsecond in the filesystems. Think about make(1) on
> a blinding fast machine...
Oh yes, I realize that. :-) It's just that I thought you were at one point
suggesting having 128 bits to the left of the decimal point (128 bits
wort
On Wed, 18 Aug 1999, Terry Lambert wrote:
> > Right. That exported struct lock * makes locking down to the lowest-level
> > file easy - you just feed it to the lock manager, and you're locking the
> > same lock the lowest level fs uses. You then lock all vnodes stacked over
> > this one at the sam
In message <199908181848.laa14...@usr02.primenet.com>, Terry Lambert writes:
>> >You would have to de-collapse several VOP lists that have been
>> >pre-collapsed.
>>
>> You are talking gibberish here. Please show code where this is
>> a problem.
>
>When you write a proxy stacking layer, such as
> >> > > I'm not familiar with the VFS_default stuff. All the vop_default_desc
> >> > > routines in NetBSD point to error routines.
> >> >
> >> > In FreeBSD, they now point to default routines that are *not* error
> >> > routines. This is the problem. I admit the change was very well
> >> > inte
The discussions between Kirk and matt over a glass of beer/drink
at kirk's party at USENIX and at the Bay area User's group.
On Wed, 18 Aug 1999, Nate Williams wrote:
> > > Matt doesn't represent the FreeBSD project, and even if he rewrites
> > > the VFS subsystem so he can understand it, his r
:On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
:
:> Matt doesn't represent the FreeBSD project, and even if he rewrites
:> the VFS subsystem so he can understand it, his rewrite would face
:> considerable resistance on its way into FreeBSD. I don't think
:> there is reason to rewrite it, but there
> > > > > > 2. Advisory locks are hung off private backing objects.
> > > I'm not sure. The struct lock * is only used by layered filesystems, so
> > > they can keep track both of the underlying vnode lock, and if needed their
> > > own vnode lock. For advisory locks, would we want to keep track b
In message ,
Julian Elischer writes:
>On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
>
>> Matt doesn't represent the FreeBSD project, and even if he rewrites
>> the VFS subsystem so he can understand it, his rewrite would face
>> considerable resistance on its way into FreeBSD. I don't think
>> th
> > Matt doesn't represent the FreeBSD project, and even if he rewrites
> > the VFS subsystem so he can understand it, his rewrite would face
> > considerable resistance on its way into FreeBSD. I don't think
> > there is reason to rewrite it, but there certainly are areas
> > that need fixing.
>
On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
> Yes, but we need subsecond in the filesystems. Think about make(1) on
> a blinding fast machine...
Oh yes, I realize that. :-) It's just that I thought you were at one point
suggesting having 128 bits to the left of the decimal point (128 bits
wor
On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
> Matt doesn't represent the FreeBSD project, and even if he rewrites
> the VFS subsystem so he can understand it, his rewrite would face
> considerable resistance on its way into FreeBSD. I don't think
> there is reason to rewrite it, but there cer
In message , Bill
Studenmund writes:
>> >I doubt we need more than 64 bit times. 2^63 seconds works out to
>> >292,279,025,208 years, or 292 (american) billion years. Current theories
>> >put the age of the universe at I think 12 to 16 billion years. So 64-bit
>> >signed times in seconds will cov
On Wed, 18 Aug 1999, Terry Lambert wrote:
> > Right. That exported struct lock * makes locking down to the lowest-level
> > file easy - you just feed it to the lock manager, and you're locking the
> > same lock the lowest level fs uses. You then lock all vnodes stacked over
> > this one at the sa
In message <199908181737.laa03...@mt.sri.com>, Nate Williams writes:
>> > Both struct timespec and struct timeval are major mistakes, they
>> > make arithmetic on timestamps an expensive operation. Timestamps
>> > should be stored as integers using an fix-point notations, for
>> > instance 64bits
In message <[EMAIL PROTECTED]>, Terry Lambert writes:
>> >You would have to de-collapse several VOP lists that have been
>> >pre-collapsed.
>>
>> You are talking gibberish here. Please show code where this is
>> a problem.
>
>When you write a proxy stacking layer, such as John Heidemann's
>netw
On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
> In message ,
> Bill Studenmund writes:
>
> >Whew! That's reasuring. I agree there are things which need fixing. It'd
> >be nice if both NetBSD and FreeBSD could fix things in the same way.
>
> Well, >that< still remains to be seen...
:-)
> >I do
> >> > > I'm not familiar with the VFS_default stuff. All the vop_default_desc
> >> > > routines in NetBSD point to error routines.
> >> >
> >> > In FreeBSD, they now point to default routines that are *not* error
> >> > routines. This is the problem. I admit the change was very well
> >> > int
The discussions between Kirk and matt over a glass of beer/drink
at kirk's party at USENIX and at the Bay area User's group.
On Wed, 18 Aug 1999, Nate Williams wrote:
> > > Matt doesn't represent the FreeBSD project, and even if he rewrites
> > > the VFS subsystem so he can understand it, his
> > Both struct timespec and struct timeval are major mistakes, they
> > make arithmetic on timestamps an expensive operation. Timestamps
> > should be stored as integers using an fix-point notations, for
> > instance 64bits with 32bit fractional seconds (the NTP timestamp),
> > or in the future 1
In message , Bill
Studenmund writes:
>Whew! That's reasuring. I agree there are things which need fixing. It'd
>be nice if both NetBSD and FreeBSD could fix things in the same way.
Well, >that< still remains to be seen...
>> >> The use of the "vfs_default" to make unimplemented VOP's
>> >>
:On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
:
:> Matt doesn't represent the FreeBSD project, and even if he rewrites
:> the VFS subsystem so he can understand it, his rewrite would face
:> considerable resistance on its way into FreeBSD. I don't think
:> there is reason to rewrite it, but ther
On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
> In message ,
> Bill
> Studenmund writes:
> >On Sat, 14 Aug 1999, Terry Lambert wrote:
>
> Matt doesn't represent the FreeBSD project, and even if he rewrites
> the VFS subsystem so he can understand it, his rewrite would face
> considerable resist
In message <199908181716.kaa12...@usr02.primenet.com>, Terry Lambert writes:
>> > > I'm not familiar with the VFS_default stuff. All the vop_default_desc
>> > > routines in NetBSD point to error routines.
>> >
>> > In FreeBSD, they now point to default routines that are *not* error
>> > routines.
> > > > > > 2. Advisory locks are hung off private backing objects.
> > > I'm not sure. The struct lock * is only used by layered filesystems, so
> > > they can keep track both of the underlying vnode lock, and if needed their
> > > own vnode lock. For advisory locks, would we want to keep track
In message <[EMAIL PROTECTED]>, Julian
Elischer writes:
>On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
>
>> Matt doesn't represent the FreeBSD project, and even if he rewrites
>> the VFS subsystem so he can understand it, his rewrite would face
>> considerable resistance on its way into FreeBSD.
> > Matt doesn't represent the FreeBSD project, and even if he rewrites
> > the VFS subsystem so he can understand it, his rewrite would face
> > considerable resistance on its way into FreeBSD. I don't think
> > there is reason to rewrite it, but there certainly are areas
> > that need fixing.
>
> > > I'm not familiar with the VFS_default stuff. All the vop_default_desc
> > > routines in NetBSD point to error routines.
> >
> > In FreeBSD, they now point to default routines that are *not* error
> > routines. This is the problem. I admit the change was very well
> > intentioned, since it
On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
> Matt doesn't represent the FreeBSD project, and even if he rewrites
> the VFS subsystem so he can understand it, his rewrite would face
> considerable resistance on its way into FreeBSD. I don't think
> there is reason to rewrite it, but there ce
In message <[EMAIL PROTECTED]>, Bill
Studenmund writes:
>> >I doubt we need more than 64 bit times. 2^63 seconds works out to
>> >292,279,025,208 years, or 292 (american) billion years. Current theories
>> >put the age of the universe at I think 12 to 16 billion years. So 64-bit
>> >signed times
In message <[EMAIL PROTECTED]>, Nate Williams writes:
>> > Both struct timespec and struct timeval are major mistakes, they
>> > make arithmetic on timestamps an expensive operation. Timestamps
>> > should be stored as integers using an fix-point notations, for
>> > instance 64bits with 32bit fra
On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Bill
>Studenmund writes:
>
> >Whew! That's reasuring. I agree there are things which need fixing. It'd
> >be nice if both NetBSD and FreeBSD could fix things in the same way.
>
> Well, >that< still remains to be se
> > Both struct timespec and struct timeval are major mistakes, they
> > make arithmetic on timestamps an expensive operation. Timestamps
> > should be stored as integers using an fix-point notations, for
> > instance 64bits with 32bit fractional seconds (the NTP timestamp),
> > or in the future
In message <[EMAIL PROTECTED]>, Bill
Studenmund writes:
>Whew! That's reasuring. I agree there are things which need fixing. It'd
>be nice if both NetBSD and FreeBSD could fix things in the same way.
Well, >that< still remains to be seen...
>> >> The use of the "vfs_default" to make unimplem
On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Bill
> Studenmund writes:
> >On Sat, 14 Aug 1999, Terry Lambert wrote:
>
> Matt doesn't represent the FreeBSD project, and even if he rewrites
> the VFS subsystem so he can understand it, his rewrite would face
> co
In message <[EMAIL PROTECTED]>, Terry Lambert writes:
>> > > I'm not familiar with the VFS_default stuff. All the vop_default_desc
>> > > routines in NetBSD point to error routines.
>> >
>> > In FreeBSD, they now point to default routines that are *not* error
>> > routines. This is the problem.
> > > I'm not familiar with the VFS_default stuff. All the vop_default_desc
> > > routines in NetBSD point to error routines.
> >
> > In FreeBSD, they now point to default routines that are *not* error
> > routines. This is the problem. I admit the change was very well
> > intentioned, since it
In message , Bill
Studenmund writes:
>On Sat, 14 Aug 1999, Terry Lambert wrote:
>> > I am currently conducting a thorough study of the VFS subsystem
>> > in preparation for an all-out effort to port SGI's XFS filesystem to
>> > FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon
>> >
In message <[EMAIL PROTECTED]>, Bill
Studenmund writes:
>On Sat, 14 Aug 1999, Terry Lambert wrote:
>> > I am currently conducting a thorough study of the VFS subsystem
>> > in preparation for an all-out effort to port SGI's XFS filesystem to
>> > FreeBSD 4.x at such time as SGI gives up the code
Don Lewis wrote:
>
> On Aug 16, 9:18pm, Terry Lambert wrote:
> } Subject: Re: BSD XFS Port & BSD VFS Rewrite
>
> } > I don't see how the namei recursion method prevents catching // as a
> } > namespace escape.
> }
> }
> } //apple-resource-fork/inte
Don Lewis wrote:
>
> On Aug 16, 9:18pm, Terry Lambert wrote:
> } Subject: Re: BSD XFS Port & BSD VFS Rewrite
>
> } > I don't see how the namei recursion method prevents catching // as a
> } > namespace escape.
> }
> }
> } //apple-resource-fork/inte
On Aug 16, 9:18pm, Terry Lambert wrote:
} Subject: Re: BSD XFS Port & BSD VFS Rewrite
} > I don't see how the namei recursion method prevents catching // as a
} > namespace escape.
}
}
} //apple-resource-fork/intermediate_dir/some_other_dir/file_with_fork
}
} You can't i
On Aug 16, 9:18pm, Terry Lambert wrote:
} Subject: Re: BSD XFS Port & BSD VFS Rewrite
} > I don't see how the namei recursion method prevents catching // as a
} > namespace escape.
}
}
} //apple-resource-fork/intermediate_dir/some_other_dir/file_with_fork
}
} You can't i
I forgot I had some old diffs that may be of help,
http://www.freebsd.org/~mch/vop1a.diff
You'll notice that just about everywhere that I moved vput() to the
appropriate layer a path component buffer was also freed in the wrong
place. John Dyson put these buffers in zones so the free routine prob
> > Have you tried Heidemann's student's stacking layers? There is one
> > encryption, and one per-file compression with namespace hiding, that
> > I think it would be hard pressed to keep up with. But I'll give it
> > the benefit of the doubt. 8-).
>
> Nope. The problem is that while stacking
On Wed, 18 Aug 1999, Michael Hancock wrote:
> Interesting, have you read the Heidemann paper that outlines a solution
> that uses a cache manager?
>
> You can probably find it somewhere here,
> http://www.isi.edu/~johnh/SOFTWARE/UCLA_STACKING/
Nope. I've read his dissertation, and his discussion
I forgot I had some old diffs that may be of help,
http://www.freebsd.org/~mch/vop1a.diff
You'll notice that just about everywhere that I moved vput() to the
appropriate layer a path component buffer was also freed in the wrong
place. John Dyson put these buffers in zones so the free routine pro
> > Have you tried Heidemann's student's stacking layers? There is one
> > encryption, and one per-file compression with namespace hiding, that
> > I think it would be hard pressed to keep up with. But I'll give it
> > the benefit of the doubt. 8-).
>
> Nope. The problem is that while stacking
On Wed, 18 Aug 1999, Michael Hancock wrote:
> Interesting, have you read the Heidemann paper that outlines a solution
> that uses a cache manager?
>
> You can probably find it somewhere here,
> http://www.isi.edu/~johnh/SOFTWARE/UCLA_STACKING/
Nope. I've read his dissertation, and his discussio
On Tue, 17 Aug 1999, Terry Lambert wrote:
> > > > > 2.Advisory locks are hung off private backing objects.
> > I'm not sure. The struct lock * is only used by layered filesystems, so
> > they can keep track both of the underlying vnode lock, and if needed their
> > own vnode lock. For advisory
On Tue, 17 Aug 1999, Terry Lambert wrote:
> > > > > 2.Advisory locks are hung off private backing objects.
> > I'm not sure. The struct lock * is only used by layered filesystems, so
> > they can keep track both of the underlying vnode lock, and if needed their
> > own vnode lock. For advisor
1 - 100 of 226 matches
Mail list logo
