Thanks much Hifumi!
Chris, please comment on the patch.
Hans
Hifumi Hisashi wrote:
> Hello.
>
> I noticed that the Reiserfs has some problems related to meta-data
> journaling.
> I suppose that transactions regarding meta-data should be written to
> a disk every
> meta-data change (for ex
3.6 will always be supported for bug fixes, but will not receive new
features if I can help it. It is stable supported code, and should be
kept that way.
Regarding the journaling implementation, let's see what Chris says
before I comment.
Hans
michael chang wrote:
>On 8/31/05, Hifumi Hisashi <
vs will respond at the end of the week, he is out at the moment.
Thanks for patch Charles,
Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Daniel Phillips wrote:
> Graciously accepted. Coming up with something sensible in a mere 6
> months would be a minor miracle. ;-)
>
> - what happens if the user forgets to close the transaction?
then the user has branched into his own version, or at least that would be my
take on it. Another
Daniel Phillips wrote:
>
> On Tuesday 22 May 2001 22:10, Andreas Dilger wrote:
> > Peter Braam writes:
> > > File system journal recovery can corrupt a snapshot, because it
> > > copies data that needs to be preserved in a snapshot. During
> > > journal replay such data may be copied again, but t
is only one problem left:
>
> On Sat, 28 Oct 2000, Hans Reiser wrote:
> > Anton Altaparmakov wrote:
> > > How would you distinguish the file filename/1 from the named stream filename/1?
> >
> > I wouldn't, they are the same thing. If you need to emulate some
Anton Altaparmakov wrote:
>
> Hans,
>
> At 18:30 28/10/2000, Hans Reiser wrote:
> >Anton Altaparmakov wrote:
> > > You can't possibly have both using the same API since you would then get
> > > name collision on filesystems where both named streams an
Anton Altaparmakov wrote:
>
> At 11:00 28/10/2000, Hans Reiser wrote:
> >Curtis Anderson wrote:
> >
> > > The problem with streams-style attributes comes from stepping onto the
> > > slippery slope of trying to put too much generality into it. I chose the
>
Chris Mason wrote:
>
> --On 10/27/00 14:33:33 -0700 Hans Reiser <[EMAIL PROTECTED]> wrote:
>
> > The atomic restriction can be enforced in a component separate. I mean,
> > ACLs have all sorts of restrictions on them, and atomicity is one of a
> > great ma
Curtis Anderson wrote:
>
> Hans Reiser wrote:
> > Curtis Anderson wrote:
> > > The problem with streams-style attributes comes from stepping onto the
> > > slippery slope of trying to put too much generality into it. I chose the
> > > block-access
Curtis Anderson wrote:
> The problem with streams-style attributes comes from stepping onto the
> slippery slope of trying to put too much generality into it. I chose the
> block-access style of API so that there would be no temptation to start
> down that slope.
I understand you right up until
"Stephen C. Tweedie" wrote:
> > Does any filesystem implement an ordered list?
>
> For ACLs, yes. For named attributes, a few do, most don't.
Why not make ordering an optional feature of directories? Then you don't need this,
and the
ordering feature is kept orthogonal from the other attribu
"Stephen C. Tweedie" wrote:
>
> Hi,
>
> On Fri, Oct 27, 2000 at 02:33:33PM -0700, Hans Reiser wrote:
>
> > > On Thu, Oct 26, 2000 at 09:26:22PM -0700, Hans Reiser wrote:
>
> > > The API here is designed *exclusively* for non-streamlike att
"Stephen C. Tweedie" wrote:
>
> Hi,
>
> On Thu, Oct 26, 2000 at 09:26:22PM -0700, Hans Reiser wrote:
> > You are making extended attributes different from files in more than name. This
>is deeply and
> > fundamentally wrong.
>
> ACLs, MACs etc _are
Curtis Anderson wrote:
>
> Hans Reiser wrote:
> > You are making extended attributes different from files in more than name.
> > This is deeply and fundamentally wrong.
>
> When I developed the EA's that are in SGI's XFS, I had to decide between
> b
You are making extended attributes different from files in more than name. This is
deeply and
fundamentally wrong.
"Stephen C. Tweedie" wrote:
>
> Hi,
>
> On Wed, Oct 25, 2000 at 09:52:28AM -0700, Hans Reiser wrote:
>
> > > However, that breaks for GETAL
"Stephen C. Tweedie" wrote:
>
> Hi,
>
> On Wed, Oct 25, 2000 at 03:52:34PM -0700, Hans Reiser wrote:
>
> > > There already exist filesystems where named streams and named atomic
> > > attributes both already exist. We need to differentiate between th
Ragnar Kjørstad wrote:
>
> On Wed, Oct 25, 2000 at 09:15:40AM -0700, Hans Reiser wrote:
> > Users complained that "reiserfs" was too long, and said they just called
> > it "reiser" in conversation
> > anyway. I don't really care, I keep changing
"Stephen C. Tweedie" wrote:
>
> Hi,
>
> On Wed, Oct 25, 2000 at 08:45:28AM -0700, Hans Reiser wrote:
>
> > reiser4_sandbox(char * command, int string_length)
> >
> > where command has a syntax of:
> >
> > "lhs<=rhs;lhs<=rhs;lhs&
"Stephen C. Tweedie" wrote:
>
> Hi,
>
> On Wed, Oct 25, 2000 at 09:39:05AM -0700, Hans Reiser wrote:
>
> > > It is certainly _possible_ to allow ACLs to change on rename/link, but
> > > POSIX ACLs don't do that. Other filesystems may well do.
&
"Stephen C. Tweedie" wrote:
>
> Hi,
>
> On Wed, Oct 25, 2000 at 08:45:28AM -0700, Hans Reiser wrote:
>
> > Extended attributes should be accessed by an interface that accesses them as files
>with a particular
> > name.
>
> That is a good goal
"Stephen C. Tweedie" wrote:
>
> Hi,
>
> On Wed, Oct 25, 2000 at 09:09:57AM -0700, Hans Reiser wrote:
>
> > Why do you force the user to copy the data into the attrib structure, rather than
>letting him leave
> > the data where it lies and simply specify
"Stephen C. Tweedie" wrote:
>
> Hi,
>
> On Tue, Oct 24, 2000 at 02:30:24PM +0100, Stephen C. Tweedie wrote:
>
> > > Why do you treat attributes differently from files? Why is your interface
>specific to attributes
> > > rather than files generally with attributes being files with a particular
"Juan J. Quintela" wrote:
>
> >>>>> "hans" == Hans Reiser <[EMAIL PROTECTED]> writes:
>
> Hi
>
> hans> Suppose /a is permissions 700 and /b is 777, and you rename
> hans> /a/foo to /b/foo, you have then changed the permis
"Stephen C. Tweedie" wrote:
>
> Hi,
>
> On Wed, Oct 25, 2000 at 08:57:43AM -0700, Hans Reiser wrote:
>
> > > POSIX makes an unambiguous definition of inheritence --- inheritence
> > > is applied on file creation. Hard links only create a new direct
Why do you force the user to copy the data into the attrib structure, rather than
letting him leave
the data where it lies and simply specify the location to the kernel?
Why do you treat attributes differently from files? Why is your interface specific to
attributes
rather than files generally
"Stephen C. Tweedie" wrote:
>
> Hi,
>
> On Tue, Oct 24, 2000 at 09:20:05AM +0200, Ragnar Kj?rstad wrote:
>
> > I don't know how much need there is for inheritence here, but if a lot
> > of attributes will need it I think it should be supported in the
> > interface instead. (though hardlinks rea
gnar Kjørstad wrote:
>
> CCed to openxdsm because we need extended attributes and Hans Reiser
> because I know he has comments but didn't reply to your mail.
>
> On Sun, Oct 22, 2000 at 04:23:53PM +0200, Andreas Gruenbacher wrote:
> > Hello,
> >
> > This is
28 matches
Mail list logo
