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 <[EMAIL PROTECTED]> said:
> On Monday 28 May 2001 03:26, Horst von Brand wrote:
> > Daniel Phillips <[EMAIL PROTECTED]> said:
> > > On Sunday 27 May 2001 15:32, Edgar Toernig wrote:
> >
> > [...]
> >
> > > > you break UNIX fundamentals. But I'm quite relieved now because
> > > > I
On Sun, May 27, 2001 at 10:45:17PM +0200, Daniel Phillips wrote:
> On Sunday 27 May 2001 15:32, Edgar Toernig wrote:
> > Daniel Phillips wrote:
> > > I'm not claiming there isn't breakage somewhere,
> >
> > you break UNIX fundamentals. But I'm quite relieved now because I'm
> > pretty sure that s
On Sunday 27 May 2001 15:32, Edgar Toernig wrote:
> Daniel Phillips wrote:
> > It won't, the open for "." is handled in the VFS, not the
> > filesystem - it will open the directory. (Without needing to be
> > told it's a directory via O_DIRECTORY.) If you do open("magicdev")
> > you'll get the d
Daniel Phillips wrote:
>
> It won't, the open for "." is handled in the VFS, not the filesystem -
> it will open the directory. (Without needing to be told it's a
> directory via O_DIRECTORY.) If you do open("magicdev") you'll get the
> device, because that's handled by magicdevfs.
You really
Daniel Phillips wrote:
>
> Oops, oh wait, there's already another open point: your breakage
> examples both rely on opening ".". You're right, "." should always be
> a directory and I believe that's enforced by the VFS. So we don't have
> an example of breakage yet.
That's just because I did a
On Thursday 24 May 2001 22:59, Edgar Toernig wrote:
> Daniel Phillips wrote:
> > > > Readdir fills in a directory type, so ls sees it as a directory
> > > > and does the right thing. On the other hand, we know we're on
> > > > a device filesystem so we will next open the name as a regular
> > > >
On Friday 25 May 2001 00:00, Hans Reiser wrote:
> Daniel Phillips wrote:
> > I suppose I'm just reiterating the obvious, but we should
> > eventually have a generic filesystem transaction API at the VFS
> > level, once we have enough data points to know what the One True
> > API should be.
>
> Dan
On Thursday 24 May 2001 23:26, Alexander Viro wrote:
> On Thu, 24 May 2001, Edgar Toernig wrote:
> > > What *won't* happen is, you won't get side effects from opening
> > > your serial ports (you'd have to open them without O_DIRECTORY
> > > to get that) so that seems like a little step forward.
>
On Thursday 24 May 2001 16:39, Oliver Xymoron wrote:
> On Thu, 24 May 2001, Marko Kreen wrote:
> > On Thu, May 24, 2001 at 02:23:27AM +0200, Edgar Toernig wrote:
> > > Daniel Phillips wrote:
> > > > > > It's going to be marked 'd', it's a directory, not a file.
> > > > >
> > > > > Aha. So you los
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
On Thu, 24 May 2001, Edgar Toernig wrote:
> > What *won't* happen is, you won't get side effects from opening
> > your serial ports (you'd have to open them without O_DIRECTORY
> > to get that) so that seems like a little step forward.
>
> As already said: depending on O_DIRECTORY breaks POSIX
Daniel Phillips wrote:
>
> > > Readdir fills in a directory type, so ls sees it as a directory and
> > > does the right thing. On the other hand, we know we're on a device
> > > filesystem so we will next open the name as a regular file, and
> > > find ISCHR or ISBLK: good.
> >
> > ??? The kerne
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 the source can
> > have new data alre
On Thursday 24 May 2001 02:23, Edgar Toernig wrote:
> Daniel Phillips wrote:
> > > > It's going to be marked 'd', it's a directory, not a file.
> > >
> > > Aha. So you lose the S_ISCHR/BLK attribute.
> >
> > Readdir fills in a directory type, so ls sees it as a directory and
> > does the right th
[cc list reduced]
Andreas Dilger writes:
> PS - I used to think shrinking a filesystem online was useful, but there
> are a huge amount of problems with this and very few real-life
> benefits, as long as you can at least do offline shrinking. With
> proper LVM usage, the need to s
On Thu, May 24, 2001 at 02:23:27AM +0200, Edgar Toernig wrote:
> Daniel Phillips wrote:
> > > > It's going to be marked 'd', it's a directory, not a file.
> > >
> > > Aha. So you lose the S_ISCHR/BLK attribute.
> >
> > Readdir fills in a directory type, so ls sees it as a directory and does
> >
Daniel Phillips wrote:
> On Wednesday 23 May 2001 06:19, Edgar Toernig wrote:
> > Daniel Phillips wrote:
> > > On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote:
> > > > On Mon, 21 May 2001, Daniel Phillips wrote:
> > > > > On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
> > > > > > What I'd l
On Wednesday 23 May 2001 06:19, Edgar Toernig wrote:
> IMO the whole idea of arguments following the device name is junk
> (incl a "/ctrl").
You know I didn't suggest that, right? I find it pretty strange too, but
I'm listening to hear the technical arguments.
> Just think about the implication
On Wednesday 23 May 2001 06:19, Edgar Toernig wrote:
> Daniel Phillips wrote:
> > On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote:
> > > On Mon, 21 May 2001, Daniel Phillips wrote:
> > > > On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
> > > > > What I'd like to see:
> > > > >
> > > > > - A
Hi,
On Tue, May 22, 2001 at 01:16:42PM -0600, Peter J. Braam wrote:
> File system journal recovery can corrupt a snapshot, because it copies
> data that needs to be preserved in a snapshot.
Journal recovery may move data from the journal to other locations on
the device, yes, but that doesn't
On Wed, 23 May 2001, Edgar Toernig wrote:
> And with special "ctrl" devices (ie /dev/ttyS0 and /dev/ttyS0ctrl):
> This _may_ work for some kind of devices. But serial ports are one
> example where it simply will _not_. It requires that you know the
That's quite funny, you know...
--
Daniel Phillips wrote:
>
> On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote:
> > On Mon, 21 May 2001, Daniel Phillips wrote:
> > > On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
> > > > What I'd like to see:
> > > >
> > > > - An interface for registering an array of related devices
> > > >
Andreas,
I think that the issue is something different. Suppose the snapshot has
been created. I know that this can be done safely with the API's you
allude to. Life goes on and the journal FS keeps changing the file system
and if the system doesn't crash, everything is fine: blocks get copied
On Tuesday 22 May 2001 19:49, Oliver Xymoron wrote:
> On Tue, 22 May 2001, Daniel Phillips wrote:
> > > I don't think it's likely to be even workable. Just consider the
> > > directory entry for a moment - is it going to be marked d or
> > > [cb]?
> >
> > It's going to be marked 'd', it's a direct
On Tue, 22 May 2001, Linus Torvalds wrote:
>
> On Tue, 22 May 2001, Andreas Dilger wrote: Actually, the LVM snapshot
> interface has (optional) hooks into the filesystem to ensure that it
> is consistent at the time the snapshot is created.
But I think that LVM is implemented "the wrong way a
On Tue, 22 May 2001, Andreas Dilger wrote:
>
> Actually, the LVM snapshot interface has (optional) hooks into the filesystem
> to ensure that it is consistent at the time the snapshot is created.
Note that this is still fundamentally a broken interface: the filesystem
may not _have_ a block dev
On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote:
> On Mon, 21 May 2001, Daniel Phillips wrote:
> > On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
> > > What I'd like to see:
> > >
> > > - An interface for registering an array of related devices
> > > (almost always two: raw and ctl) and the
On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
> What I'd like to see:
>
> - An interface for registering an array of related devices (almost
> always two: raw and ctl) and their legacy device numbers with a
> single userspace callout that does whatever /dev/ creation needs to
> be done. Thus,
On Sun, 20 May 2001, Pavel Machek wrote:
> Hi!
>
> > A lot of stuff relies on the fact that close(open(foo, O_RDONLY)) is a
> > no-op. Breaking that assumption is a Bad Thing(tm).
>
> Then we have a problem. Just opening /dev/ttyS0 currently *has* side
> effects (it is visible on modem lines
Hi!
> So I guess things have already been a bit messy in this
> area for many years, even before linux even existed, and
> in some cases you can't really do anything about it because
> the behaviour is mandated by the applicable standards, like
> POSIX, SUS, or whatever.
> (The blocking of the op
Hi!
> Yes, and that is exactly the difference between having a side effect
> on the open(2), versus having the effect as a result of a write(2).
>
> Unfortunately, there are already some cases where an open
> on a device can have unexpected results. If you don't want
> to get blocked waiting fo
On Mon, 21 May 2001, David Lang wrote:
> what makes you think it's safe to say there's only one floppy drive?
Read as: it doesn't make sense to have per-fd state on a single floppy
device given that there's only one actual hardware instance associated
with it and multiple openers don't make sens
what makes you think it's safe to say there's only one floppy drive?
David Lang
On Mon, 21 May 2001, Oliver Xymoron wrote:
> On Sat, 19 May 2001, Alexander Viro wrote:
>
> > Let's distinguish between per-fd effects (that's what name in
> > open(name, flags) is for - you are asking for descripto
On Sat, 19 May 2001, Jeff Garzik wrote:
> Why are LVM and EVMS(competing LVM project) needed at all?
>
> Surely the same can be accomplished with
> * md
> * snapshot blkdev (attached in previous e-mail)
> * giving partitions and blkdevs the ability to grow and shrink
> * giving filesystems the ab
On Sat, 19 May 2001, Alexander Viro wrote:
> Let's distinguish between per-fd effects (that's what name in
> open(name, flags) is for - you are asking for descriptor and telling
> what behaviour do you want for IO on it) and system-wide side effects.
>
> IMO encoding the former into name is perfe
On Sat, 19 May 2001 [EMAIL PROTECTED] wrote:
> One would like to have a version of the open() call that was
> guaranteed free of side effects, and gave a fd only -
> perhaps for stat(), perhaps for ioctl().
I did this a while ago, after some discussion. The
implementation may suck, but I think
Here's a dumb question, and I apologize if I am questioning computer
science dogma...
Why are LVM and EVMS(competing LVM project) needed at all?
Surely the same can be accomplished with
* md
* snapshot blkdev (attached in previous e-mail)
* giving partitions and blkdevs the ability to grow and s
Linus Torvalds wrote:
> There are some strong arguments that we should have filesystem
> "backdoors" for maintenance purposes, including backup.
I think I agree with something Al said over IRC, that fs-level snapshots
are preferred over block level snapshots.
fs-level snapshots should become eas
On Sun, 20 May 2001, Edgar Toernig wrote:
> That assumption is totally bogus. Even for regular files you have side
> effects (atime); for anything else they're unpredictable.
That means only one thing: safe backups are possible only in single-user
mode. For values of safe being "not triggerin
nitpicking: a system call without side effects would be pretty useless.
Alexander Viro wrote:
> A lot of stuff relies on the fact that close(open(foo, O_RDONLY)) is a
> no-op. Breaking that assumption is a Bad Thing(tm).
That assumption is totally bogus. Even for regular files you have side
eff
On Sat, 19 May 2001, Jeff Garzik wrote:
> Are we talking about device arguments just for chrdevs and blkdevs?
> (ie. drivers) or for regular files too?
Let's distinguish between per-fd effects (that's what name in open(name, flags)
is for - you are asking for descriptor and telling what beha
Jeff Garzik wrote:
> Notice also a "metadata miscdev" solves the problem of passing options
> on open -- just pass those options to the miscdev before you open it...
to be more clear, "it" == the data device, not the metadata miscdev
--
Jeff Garzik | "Do you have to make light of everythin
Are we talking about device arguments just for chrdevs and blkdevs?
(ie. drivers) or for regular files too?
Speaking about drivers specifically, a controlling miscdev, one per
device or one per group of devices depending on your needs, is a much
more clean solution for passing ioctl-type data.
On Sat, 19 May 2001, Matthew Wilcox wrote:
> On Sat, May 19, 2001 at 12:51:07PM -0400, Alexander Viro wrote:
> > clone(), walk(), clunk(), stat() and open() ;-) Basically, we can add
> > unopened descriptors. I.e. no IO until you open it (turning the thing into
> > opened one), but we can do lo
On Sat, 19 May 2001, Linus Torvalds wrote:
>
> On Sat, 19 May 2001, Alexander Viro wrote:
> >
> > Folks, before you get all excited about cramming side effects into
> > open(2), consider the following case:
>
> Your argument is stupid, imnsho.
>
> Side-effects are perfectly fine if they
On Sat, 19 May 2001, Alexander Viro wrote:
>
> Folks, before you get all excited about cramming side effects into
> open(2), consider the following case:
Your argument is stupid, imnsho.
Side-effects are perfectly fine if they are _local_ to the file
descriptor. Your example is contrieved
On Sat, May 19, 2001 at 12:51:07PM -0400, Alexander Viro wrote:
> clone(), walk(), clunk(), stat() and open() ;-) Basically, we can add
> unopened descriptors. I.e. no IO until you open it (turning the thing into
> opened one), but we can do lookups (move to child), we can clone and
> kill them an
On Sat, 19 May 2001 [EMAIL PROTECTED] wrote:
> One would like to have a version of the open() call that was
> guaranteed free of side effects, and gave a fd only -
> perhaps for stat(), perhaps for ioctl().
> This guarantee could perhaps be obtained by omitting the
> f->f_op->open(inode,f
>> Opening device files often has interesting side effects.
> Too bad. They can be triggered by similar races between attacker
> changing the type of object (file<->symlink) and backup.
Yes. This is a well-known security problem.
Doing
stat("file", &s);
if (action desired) {
Abramo Bagnara wrote:
> Alexander Viro wrote:
> > Folks, before you get all excited about cramming side effects into
> > open(2), consider the following case:
> >
> > 1) opening "/dev/zero/start_nuclear_war" has a certain side effect.
[...]
> Can't this easily avoided if the needed action
On Sat, 19 May 2001, Abramo Bagnara wrote:
> Can't this easily avoided if the needed action is not
>
> < /dev/zero/start_nuclear_war
> or
> > /dev/zero/start_nuclear_war
>
> but
>
> echo "I'm evil" > /dev/zero/start_nuclear_war
Sure. And that's the right thing to do (not the implied action
Alexander Viro wrote:
>
> Folks, before you get all excited about cramming side effects into
> open(2), consider the following case:
>
> 1) opening "/dev/zero/start_nuclear_war" has a certain side effect.
>
> 2) Local user does the following:
> ln -sf /dev/zero/start_nuclear_war
On Sat, 19 May 2001 [EMAIL PROTECTED] wrote:
> > A lot of stuff relies on the fact that close(open(foo, O_RDONLY))
> > is a no-op. Breaking that assumption is a Bad Thing(tm).
>
> Also here I would like to agree. Unfortunately this is false.
> Opening device files often has interesting side ef
Alexander Viro writes:
> Folks, before you get all excited about cramming side effects
> into open(2), consider ...
I agree completely.
> A lot of stuff relies on the fact that close(open(foo, O_RDONLY))
> is a no-op. Breaking that assumption is a Bad Thing(tm).
Also here I would like to agree
55 matches
Mail list logo
