J. Bruce Fields [EMAIL PROTECTED] wrote:
Do you allow upgrades and downgrades? (Just curious.)
AFS does not, as far as I know.
So if I request a write lock while holding a read lock, my request will
be denied?
At the moment, yes. Don't the POSIX and flock lock-handling routines in
On the other hand, if you actually want to protect the _data_, then
tagging the _name_ is flawed; tag the *DATA* instead.
Would it make sense to label the data (resource) with a list of paths
(names) that can be used to access it?
Therefore the data would be protected against being accessed
CC trimmed to remove a few poor overloaded inboxes from this tangent.
On May 27, 2007, at 04:34:10, Cliffe wrote:
Kyle wrote:
On the other hand, if you actually want to protect the _data_,
then tagging the _name_ is flawed; tag the *DATA* instead.
Would it make sense to label the data
On May 27, 2007, at 03:25:27, Toshiharu Harada wrote:
2007/5/27, Kyle Moffett [EMAIL PROTECTED]:
On May 26, 2007, at 19:08:56, Toshiharu Harada wrote:
2007/5/27, James Morris [EMAIL PROTECTED]:
On Sat, 26 May 2007, Kyle Moffett wrote:
AppArmor). On the other hand, if you actually want to
--- Cliffe [EMAIL PROTECTED] wrote:
On the other hand, if you actually want to protect the _data_, then
tagging the _name_ is flawed; tag the *DATA* instead.
Would it make sense to label the data (resource) with a list of paths
(names) that can be used to access it?
Program Access
On Sun, May 27, 2007 at 09:51:10AM +0100, David Howells wrote:
J. Bruce Fields [EMAIL PROTECTED] wrote:
So if I request a write lock while holding a read lock, my request will
be denied?
At the moment, yes. Don't the POSIX and flock lock-handling routines in the
kernel normally do that
On Sat, May 26, 2007 at 02:29:48AM +0400, Alexey Dobriyan wrote:
===
[ INFO: possible circular locking dependency detected ]
2.6.22-rc2 #1
---
mplayer/16241 is trying to acquire lock:
Thanks everyone for your input. There was some very valuable
observations in the various emails.
I will try to pull most of it together and bring out what seem to be
the important points.
1/ A BIO_RW_BARRIER request should never fail with -EOPNOTSUP.
This is certainly a very attractive
On Friday May 25, [EMAIL PROTECTED] wrote:
2007/5/25, Neil Brown [EMAIL PROTECTED]:
- Are there other bit that we could handle better?
BIO_RW_FAILFAST? BIO_RW_SYNC? What exactly do they mean?
BIO_RW_FAILFAST: means low-level driver shouldn't do much (or no)
error recovery. Mainly
On Mon, May 28, 2007 at 11:30:32AM +1000, Neil Brown wrote:
Thanks everyone for your input. There was some very valuable
observations in the various emails.
I will try to pull most of it together and bring out what seem to be
the important points.
1/ A BIO_RW_BARRIER request should
On Monday May 28, [EMAIL PROTECTED] wrote:
On Mon, May 28, 2007 at 11:30:32AM +1000, Neil Brown wrote:
Thanks everyone for your input. There was some very valuable
observations in the various emails.
I will try to pull most of it together and bring out what seem to be
the important
On Mon, May 28, 2007 at 12:57:53PM +1000, Neil Brown wrote:
On Monday May 28, [EMAIL PROTECTED] wrote:
On Mon, May 28, 2007 at 11:30:32AM +1000, Neil Brown wrote:
Thanks everyone for your input. There was some very valuable
observations in the various emails.
I will try to pull most
Hi,
--On 28 May 2007 12:45:59 PM +1000 David Chinner [EMAIL PROTECTED] wrote:
On Mon, May 28, 2007 at 11:30:32AM +1000, Neil Brown wrote:
Thanks everyone for your input. There was some very valuable
observations in the various emails.
I will try to pull most of it together and bring out
13 matches
Mail list logo
