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'm pretty sure that
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 mean
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 device,
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 something
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.
Daniel,
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 simple
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
file, and find
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.
As
[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
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
the right thing.
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
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 already.
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:
- An interface for
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 their legacy
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
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,
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
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 open on
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 ability
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 perfectly
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 from
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 descriptor and
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
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 bar
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.
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
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 is not
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, that is -
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 and
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
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.
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 easy
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 effects.
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) {
36 matches
Mail list logo
