)
+ seq_printf(seq, ,mode=%03o, config.mode);
I would rather this be unconditional, than that it be conditional on
something other than the user having specified it in the first place.
Other than that,
Acked-by: H. Peter Anvin [EMAIL PROTECTED]
-hpa
-
To unsubscribe from this list: send
Miklos Szeredi wrote:
[autofs patch]
Acked-by: H. Peter Anvin [EMAIL PROTECTED]
-
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
Pavel Machek wrote:
On Sun 2008-01-20 09:23:00, Miklos Szeredi wrote:
Miklos Szeredi wrote:
- for mount ID's use IDA (from the IDR library) instead of a 32bit
counter, which could overflow
IDAs tend to get reused quickly, which can cause race conditions. Any
reason not to just use a 64-bit
Miklos Szeredi wrote:
- for mount ID's use IDA (from the IDR library) instead of a 32bit
counter, which could overflow
IDAs tend to get reused quickly, which can cause race conditions. Any
reason not to just use a 64-bit counter?
-hpa
-
To unsubscribe from this list: send the
Andrew Morton wrote:
Seems like a plain bad idea to me. There will be any number of home-made
/proc/mounts parsers and we don't know what they do.
There is a lot of precedent for adding fields at the end. Since the
last fields in current /proc/*/mounts are dummy fields anyway, it
doesn't
Christoph Hellwig wrote:
On Fri, Nov 09, 2007 at 05:03:01PM -0800, H. Peter Anvin wrote:
Endian-independent code is slower than wrong-endian code, because of the
necessary conditionals. Thus, you DO NOT WANT this(*).
I'd prefer not to have it either. But a someone (pinhead) was smart
enough
Andi Drebes wrote:
Indeed, this is the problem. The readme file fs/cramfs/README states:
One part of that is addressing endianness. The two options here are
`always use little-endian' (like ext2fs) or `writer chooses
endianness; kernel adapts at runtime'. Little-endian wins because of
code
Christoph Hellwig wrote:
On Wed, Nov 07, 2007 at 09:51:48PM +0100, Andi Drebes wrote:
Hi!
I would suggest you to use squashfs instead of cramfs.
First, it's newer, it's better, it's actively developed, it doesn't have any
limits like the bad cramfs.
I'm developing a new linux based firmware
Mike Waychison wrote:
The following series is meant to clean up FIBMAP paths with the eventual goal
of allowing users to be able to FIBMAP their data.
Keep in mind FIBMAP is currently extremely expensive on some
filesystems, e.g. ext3. Therefore, additional filesystem-level work
would have
Erez Zadok wrote:
In message [EMAIL PROTECTED], Hugh Dickins writes:
On Thu, 25 Oct 2007, Pekka Enberg wrote:
With unionfs also fixed, we don't know of an absolute need for this
patch (and so, on that basis, the !wbc-for_reclaim case could indeed
be removed very soon); but as I see it, the
. Peter Anvin [EMAIL PROTECTED]
Antonino A. Daplas [EMAIL PROTECTED]
Workaround : s2ram --force --acpi_sleep 1 --vbe_mode
Status : problem is being debugged
I'm inclined to write this one off as general STR weirdness. The
problem is reproducible on 2.6.22 if CONFIG_FB
known good : ?
Submitter : Jeff Chua [EMAIL PROTECTED]
Caused-By : ?
Handled-By : H. Peter Anvin [EMAIL PROTECTED]
Antonino A. Daplas [EMAIL PROTECTED]
Workaround : s2ram --force --acpi_sleep 1 --vbe_mode
Status : problem is being debugged
Michal
Miklos Szeredi wrote:
The *at() thing basically gives you the advantages of a CWD without
the disadvantages.
For example it could be useful to implement the functionality of
find(1) as a library interface.
What the *at() interfaces really do is fix/paper over a longstanding
wart in
Jeff Garzik wrote:
What the *at() interfaces really do is fix/paper over a longstanding
wart in Unix: the cwd really should have been a standard file descriptor
(like stdin/stdout/stderr) instead of a magic piece of state maintained
in kernel space.
It's more than a wart, IMO. *at()
Jeff Garzik wrote:
Well, as Jeremy pointed out, in the absence of threads you can do the
same thing with fchdir(), however, that's much more of a hack.
My posixutils project (coreutils replacement) used fchdir(2), but that
still doesn't get you 100% race-free. It gets you close, yes.
I
Al Viro wrote:
BTW, why is fstatat called fstatat and not statat? (Same goes for
futimesat.) It does not take a file descriptor for the file argument.
Otherwise we'd also need fopenat/funlinkat, etc. Any reasons?
Ulrich having an odd taste?
Solaris compatibility.
Sun having no taste
Pavel Machek wrote:
Hi!
... or, alternatively, add a subfield to the first field (which would
entail escaping whatever separator we choose):
/dev/md6 /export ext3 rw,data=ordered 0 0
/dev/md6:/users/foo /home/foo ext3 rw,data=ordered 0 0
/dev/md6:/users/bar /home/bar ext3 rw,data=ordered 0 0
Karel Zak wrote:
(BTW, maybe we can completely remove freq, passno from
/proc/mounts, especially if we don't have care about compatibility
with /etc/{mtab,fstab} format. The freq and passno are always zero in
/proc/mounts).
But we do, since there are applications which use getmntent()
Ram Pai wrote:
the second patch made a /proc/propagation interface which had almost the
same fields, but also added fields to show the propagation type of the
mount as well as pointers to its peers and master depending on the type
of the mount.
I think the consensus seems to have a new
Ram Pai wrote:
Ok. so you think /proc/mounts can be extended easily without breaking
any userspace commands?
well lets see..
1. to disambiguate bind mounts, we have to add a field that displays the
path to the mount's root dentry from the filesystem's root
dentry. Agree?
Al Viro wrote:
On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote:
... or, alternatively, add a subfield to the first field (which would
entail escaping whatever separator we choose):
/dev/md6 /export ext3 rw,data=ordered 0 0
/dev/md6:/users/foo /home/foo ext3 rw,data=ordered 0 0
Ram Pai wrote:
Peter, I am not working on it currently. But i am interested in getting
it done. I have the seed set of patches which had Al Viro's ideas
incorporated. Infact those patches were sent on lkml 2 months back.
Shall we start with those patches?
Are these the unprivileged mount
Serge E. Hallyn wrote:
Hmm, or do you actually mean that if i'd done
mount --bind /tmp/a /tmp
mount --bind /tmp/b /tmp
mount --bind /tmp/c /tmp
that you would want to see information about the first two mounts?
Yes. Right now, you see all three without any reliable
H. Peter Anvin wrote:
I guess I suggest a single comma-separated field with flags and optional
:argument:
private
shared:peer
slave:master
unbindable
overmounted
Just realized: overmounted should presumably have a mount ID associated
with it, too
Hans-Peter Jansen wrote:
That's already handled just fine:
bash-3.1$ mkdir /tmp/'Jag är: \
en liten mask'
bash-3.1$ sudo mount -t tmpfs none '/tmp/Jag är: \
en liten mask'/
bash-3.1$ tail -1 /proc/mounts
none /tmp/Jag\040är:\040\134\012en\040liten\040mask tmpfs rw 0 0
bash-3.1$
Hmm,
Bryan Henderson wrote:
The directory is quite visible with a standard 'ls -a'. Instead,
they simply mark it as a separate volume/filesystem: i.e. the fsid
differs when you call stat(). The whole thing ends up acting rather like
our bind mounts.
Hmm. So it breaks user space quite a bit. By
Right now it is actually impossible to conclusively determine a
filesystem-relative path in the presence of bind (and possibly move)
mounts. This is highly desirable to be able to do in contexts that
involve non-Linux (or not-the-current-instance-of-Linux) accesses to the
filesystem, e.g. other
Al Viro wrote:
On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote:
... or, alternatively, add a subfield to the first field (which would
entail escaping whatever separator we choose):
/dev/md6 /export ext3 rw,data=ordered 0 0
/dev/md6:/users/foo /home/foo ext3 rw,data=ordered 0 0
Karel Zak wrote:
On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote:
We could add a field to /proc/mounts to add this information:
/dev/md6 /export ext3 rw,data=ordered 0 0 /
/dev/md6 /home/foo ext3 rw,data=ordered 0 0 /users/foo
/dev/md6 /home/bar ext3 rw,data=ordered 0 0 /users
Chuck Lever wrote:
To support NFS client performance statistics, I recently added
/proc/self/mountstats. That might be a place to add details about
--move and --bind mounts without changing the format of /proc/mounts.
I just looked at /proc/self/mountstats; it seems to have no more
Dr. David Alan Gilbert wrote:
What happens with the (sick) case of spaces in directory names?
Also is it really nicely defined that there is no way to put a space
in an option in any of the filesystems? I suppose someone
particularly sick could have a device node in a directory with a
Chuck Lever wrote:
The advantage is that it doesn't have strong user space dependencies on
its format like /proc/mounts does.
If you have NFS mount points, you will see that it includes a great deal
of additional information about each mount.
OK, I see now:
device raidtest:/export mounted
Jeremy Allison wrote:
I'm not talking WinFS, I'm talking streams. Streams are already
being used (mainly by malware writers of course - but hey, don't
you want full compatibility ? :-).
Reminds me of the Linux Journal (I believe?) article which did
viruses-on-Wine compatibility
Chris Snook wrote:
I pointed out NetApp's .snapshot directories because that's a method
that uses legal path character, but doesn't break anything. With this
method, userspace tools will have to be taught that : is suddenly a
special character.
Not to mention that the character historically
Jack Stone wrote:
But that would cause havoc with shells which use ; to seperate commands.
Using ; would defiantly break userspace
Not really. It's just a bit awkward to use, but so's the whole concept.
-hpa
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel
Alan Cox wrote:
Yes but tdskb:foo.mac[1013,1013,frob];4 is *not* elegant.
I think describing VMS pathname syntax as not elegant is kind of like
describing George W. Bush as not a genius.
POSIX is very
clear about what is acceptable as magic in a pathname, and the unix spec
even more so.
Jan Harkes wrote:
Still, anything that depends on increasing the length of file or path
names to refer to different versions will encounter problems for long
file names and deep paths because there is an upper limit on file and
path name lengths.
Then you have the Solaris variant -- rely
Trond Myklebust wrote:
I assume NetApp flags the directory specially so that a POSIX directory
read doesn't get it. I've seen that done elsewhere.
No. The directory is quite visible with a standard 'ls -a'. Instead,
they simply mark it as a separate volume/filesystem: i.e. the fsid
Jack Stone wrote:
Later, I discovered what I think are superior alternatives: RCS-style
version management on top of the filesystem, and automatic versioning
based on time instead of count of modifications. For example, make a
copy of every changed file every hour and keep it for a day
Theodore Tso wrote:
As I mentioned in my Linux.conf.au presentation a year and a half ago,
the main use of Streams in Windows to date has been for system
crackers to hide trojan horse code and rootkits so that system
administrators couldn't find them. :-)
But... that's an essential
alan wrote:
On Mon, 18 Jun 2007, Bodo Eggert wrote:
alan [EMAIL PROTECTED] wrote:
I just wish that people would learn from the mistakes of others. The
MacOS is a prime example of why you do not want to use a forked
filesystem, yet some people still seem to think it is a good idea.
Jack Stone wrote:
I hope I got the CC list right. Apologies to anyone in didn't include
and anyone I shouldn't have included.
The basic idea is to include an idea from VMS that seems to be quite
useful: version numbers for files.
The idea is that whenever you modify a file the system
Trond Myklebust wrote:
A lot of these could be fixed all at once by letting the filesystem tell
the VFS to retain the string passed to the original mount. That will
Unfortunately, the original option string (from userspace) != real
options (in kernel), see NFS. This bug should be fixed --
Miklos Szeredi wrote:
Andrew, please skip this patch, for now.
Serge found a problem with the fsuid approach: setfsuid(nonzero) will
remove filesystem related capabilities. So even if root is trying to
set the user=UID flag on a mount, access to the target (and in case
of bind, the
Andrew Morton wrote:
On Fri, 20 Apr 2007 12:25:34 +0200 Miklos Szeredi [EMAIL PROTECTED] wrote:
+static bool permit_umount(struct vfsmount *mnt, int flags)
+{
...
+ return mnt-mnt_uid == current-uid;
+}
Yes, this seems very wrong. I'd have thought that comparing user_struct*'s
would
Ram Pai wrote:
It is in FC6. I dont know the status off upstream util-linux. I did
submit the patch many times to Adrian Bunk (the then util-linux
maintainer) and got no response. I have not pushed the patches to the
new maintainer(Karel Zak?) though.
Well, do that, then :)
Seriously. The
Jan Engelhardt wrote:
On Apr 6 2007 16:16, H. Peter Anvin wrote:
- users can use bind mounts without having to pre-configure them in
/etc/fstab
This is by far the biggest concern I see. I think the security implication of
allowing anyone to do bind mounts are poorly understood.
$ whoami
James Bottomley wrote:
On Wed, 2007-02-28 at 17:28 -0800, H. Peter Anvin wrote:
James Bottomley wrote:
On Wed, 2007-02-28 at 12:42 -0500, Martin K. Petersen wrote:
4104. It's 8 bytes per hardware sector. At least for T10...
Er ... that won't look good to the 512 ATA compatibility remapping
Alan wrote:
I'm not sure. Turning, for example, the statat(dir_fd, name == NULL)
error case into fstat(dir_fd) sounds like a way for apps, admittedly
buggy ones, to be surprised. Maybe libc would be exptected to catch
the error before performing the shared system call?
At that point
Theodore Tso wrote:
In any case, the reason why I bring this up is that it would be really
nice if there was a way with a single laptop drive to be able to do
snapshots and background fsck's without having to use initrd's with
device mapper.
This is a major part of why I've been trying to
Andreas Dilger wrote:
And clearing this list when the sector is overwritten, as it will almost
certainly be relocated at the disk level.
Certainly if the overwrite is successful.
-hpa
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to
Followup to: [EMAIL PROTECTED]
By author:Pavel Roskin [EMAIL PROTECTED]
In newsgroup: linux.dev.fs.devel
Hello, David!
Thank you very much for the informative reply!
Currently there is now way to specify the permissions of the ramfs
root directory at mount time: it's always
I have Cc:'d this to the linux-fs-devel list; hopefully we can get some
communication going.
Mark Kettenis wrote:
I believe I wrote this back as well: this will affect *ALL* applications,
even those that don't need large file support. This change really needs
to happen, or any
--
[EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
"H. Peter Anvin" [EMAIL PROTECTED] writes:
6. Either way, existing binaries cannot handle stat() on 64-bit inode
Geoff Keating wrote:
Date: Mon, 30 Oct 2000 11:29:09 -0800
From: "H. Peter Anvin" [EMAIL PROTECTED]
I believe I wrote this back as well: this will affect *ALL* applications,
even those that don't need large file support. This change really needs
to happen, or a
Ben LaHaise wrote:
On Mon, 30 Oct 2000, H. Peter Anvin wrote:
6. Either way, existing binaries cannot handle stat() on 64-bit inode
filesystems.
Ideas, anyone?
Don't use filesystems that require 64 bit inode numbers until all
applications are using LFS. Personally I'd rather LFS
Geoff Keating wrote:
I would recommend not designing such filesystems, or not using them,
or having the kernel translate inode numbers.
This isn't a choice for a lot of people; again, NFS v3/v4 requires this.
Having the kernel translate inode numbers can easily kill your system by
eating
Mark Kettenis wrote:
Date: Mon, 30 Oct 2000 14:08:44 -0800
From: "H. Peter Anvin" [EMAIL PROTECTED]
If so, we'd be better off completely deprecating the old calls and make
the LFS calls the default calls (and off_t == off64_t, ino_t == ino64_t,
etc.)
Except th
58 matches
Mail list logo
