Andreas writes:
Hi again,
There were some good arguments for adding a few more features to the EA
interface. This new proposal reflects some of the discussion.
I still decline to support forks/streams through the EA interface. IMHO
that's just the wrong way to go. This doesn't
Hi,
On Wed, Nov 01, 2000 at 10:15:41PM -0800, Peter J. Braam wrote:
Will it really help? A single application write() is usually not an
interesting atom as far as file consistency is concerned --- files
will usually be written chunk by chunk, and it really is open/close
which mark
On Tue, 31 Oct 2000, Stephen C. Tweedie wrote:
Hi,
On Sun, Oct 29, 2000 at 03:15:57PM +0100, Andreas Gruenbacher wrote:
The interface described here also doesn't include Stephen's idea to allow
an ordered list of EA's under the same name. In addition to the append and
prepend
On Tue, 31 Oct 2000, Stephen C. Tweedie wrote:
Hi,
NFSv4 indeed specifies yet another variant of ACLs.
Yep. In fact, it defines a richer environment than POSIX. However, I
_think_ that for any POSIX ACL, you can define an NFSv4 list which is
equivalent in all details
Some time ago I have been working on a similar project as the
Translation Filesystem Mr Kale announced recently.
That development was for 2.2.16 and I started with the romfs. After
finding
out about clear_inodes I thought that might be a good point for freeing
information
that I dynamically
What you say is true.
BTW, I nearly fell off my chair when I saw that you, one of the true Unix
monuments on this list, showed mild signs of approval of propagation on
close, instead of write!
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Stephen
There was talk of exposing some kind of transaction API now that we have
a crop of fs's on the way that can do transactions. Has this gone
anywhere?
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
"Stephen C. Tweedie" wrote:
On Sun, Oct 29, 2000 at 02:45:32PM +0100, Andreas Gruenbacher wrote:
If so, then the client's kernel could map these id's to the proper names
when needed, right?
Yes. Exactly. You're getting the point --- it is possible for a
client to manage the mapping
Hello,
have there been any advances with ext2 btree directories so far?
I'm trying to sort out different designs for storing extended attributes.
If there were btree directories, that would be the obvious choice. On the
other hand, implementing btrees just for that purpose probably is
overkill.
"Stephen C. Tweedie" wrote:
I have to admit that when I first looked at your proposal I thought it
was overkill, but having followed the thread all the way through I now
have some appreciation of the weird wacky world out there that you are
dealing with. I think your approach is correct. Here
Hi,
On Tue, Oct 31, 2000 at 08:55:13PM +, Alan Cox wrote:
Questions:
Has the O_SYNC stuff been fixed so that more than ext2 honours this
flag ?
Not yet.
Linus, the last patch I sent you on this didn't make it in --- is it
worth my while resending, or do we need to rethink
Hi Stephen,
On Thu, 2 Nov 2000, Stephen C. Tweedie wrote:
The patch I sent fully implements O_SYNC (actually, it implements
O_DSYNC, which is allowed to skip the inode sync if the only
attribute which has changed is the timestamps) and fdatasync. It's
easy for me to make the DSYNC
12 matches
Mail list logo
