Jörn Engel wrote:
> On Wed, 16 May 2007 12:54:14 +0800, David Woodhouse wrote:
> > Personally I'd just go for 'JFFS3'. After all, it has a better claim to
> > the name than either of its predecessors :)
>
> Did you ever see akpm's facial expression when he tried to pronounce
> "JFFS2"? ;)
JFFS3
Albert Cahalan wrote:
> Please don't forget the immutable bit. ("man lsattr")
> Having both, BSD-style, would be even better.
> The immutable bit is important for working around
> software bugs and "features" that damage files.
>
> I also can't find xattr support.
Imho,
Given that the filesystem
Artem Bityutskiy wrote:
> On Wed, 2007-05-16 at 12:34 +0100, Jamie Lokier wrote:
> > Jörn Engel wrote:
> > > On Wed, 16 May 2007 12:54:14 +0800, David Woodhouse wrote:
> > > > Personally I'd just go for 'JFFS3'. After all, it has a better claim to
>
Jörn Engel wrote:
> > Almost all your static functions start with logfs_, why not this one?
>
> Because after a while I discovered how silly it is to start every
> function with logfs_. That prefix doesn't add much unless the function
> has global scope. What I didn't do was remove the prefix fr
David Weinehall wrote:
> > It is also the filesystem that tries to scale logarithmically, as Arnd
> > has noted. Maybe I should call it Log2 to emphesize this point. Log1
> > would be horrible scalability.
>
> So, log2fs... Sounds great to me.
Why Log2? Logarithmic scaling is just logarithmic
Marcin 'Qrczak' Kowalczyk wrote:
> A program to exhibit the bug:
The epoll argument rounds like select(), not like poll().
It was done deliberately.
The epoll_wait() behaviour is deliberate, so that it is possible to
wait repeatedly for short time intervals of 1 timer tick.
> It should wait one
Marcin 'Qrczak' Kowalczyk wrote:
> Is it documented?
Only on linux-kernel some time ago :)
> ftp://ftp.win.tue.nl/pub/home/aeb/linux-local/manpages/man-pages-1.70.tar.gz
> doesn't seem to say that the timeout is interpreted differently for
> poll and epoll.
It doesn't say anything about the diff
Jamie Lokier wrote:
> > Well, if the kernel measured the delay more accurately than to a clock
> > tick, it could notice that a requested 1ms would be satisifed by, say,
> > 8ms which remained from the current tick.
>
> I agree 100%! That's a good solution.
&
Marcin 'Qrczak' Kowalczyk wrote:
> > If you call select with { 0, 1 } - that is, 10 milliseconds, then
> > you get a delay between 0ms and 10ms on a 100Hz kernel.
> >
> > That is easy to measure. Just call select() in a loop and observe the
> > times.
>
> I think HZ is now 1000 on x86, so I c
Bryan Henderson wrote:
> I'd resist any interface that exposes implementation details like that.
> The user program shouldn't know anything about block allocations.
A database or file scanner that must read a lot of data can benefit
from having even a rough idea of the layout of the data on disk.
Miklos Szeredi wrote:
> 1) User must not be able to modify files or directories in a way
> which he otherwise could not do (e.g. mount a filesystem over
> /bin)
>
> 2) Suid and device semantics should be disabled within the mount
>
> 3) No other user should have access to files un
Miklos Szeredi wrote:
> That is exactly the intended effect. If I'm at my work machine (where
> I'm not an admin unfortunately) and I mount my home machine with sshfs
> (because FUSE is installed fortunately :), then I bloody well don't
> want the sysadmin or some automated script of his to go muc
Miklos Szeredi wrote:
> > It would also be nice to generalise and have virtual filesystems which
> > are able to present different views to different users. Can FUSE do
> > that already - is the userspace part told which user is doing each
> > operation?
>
> Yes.
>
> > With that, the desire for
Miklos Szeredi wrote:
> The same is true for the case when you mount an sshfs. Since you
> entered your password (or have a passwordless login to the server) you
> are authorized to browse the files on the server, but only with the
> capabilities you have there as a user. The server does the
> au
Bodo Eggert <[EMAIL PROTECTED]> wrote:
> Jamie Lokier <[EMAIL PROTECTED]> wrote:
> > Miklos Szeredi wrote:
>
> >> 4) Access should not be further restricted for the owner of the
> >> mount, even if permission bits, uid or gid would suggest
> >
Bodo Eggert <[EMAIL PROTECTED]> wrote:
> >> That is exactly the intended effect. If I'm at my work machine (where
> >> I'm not an admin unfortunately) and I mount my home machine with sshfs
> >> (because FUSE is installed fortunately :), then I bloody well don't
> >> want the sysadmin or some auto
Frank Sorenson wrote:
> > That does not make sense.
> >
> > Are you saying you cannot trust your own sshfs userspace daemon?
>
> The user who wrote the userspace code may be able to, but the system
> shouldn't trust the userspace daemon. Permissions will be enforced by
> the ssh server.
In fact
Miklos Szeredi wrote:
> > If the user wants to edit a read-only file in a tgz owned by himself,
> > why can he not _chmod_ the file and _then_ edit it?
> >
> > That said, I would _usually_ prefer that when I enter a tgz, that I
> > see all component files having the same uid/gid/permissions as the
Miklos Szeredi wrote:
> > Note that NFS checks the permissions on _both_ the client and server,
> > for a reason.
>
> Does it? If I read the code correctly the client checks credentials
> supplied by the server (or cached). But the server does the actual
> checking of permissions.
>
> Am I miss
Miklos Szeredi wrote:
> > Yes, for NFSv2, this test in nfs_permssion():
> >
> > if (!NFS_PROTO(inode)->access)
> > goto out;
>
> I've seen that, I just thought that was for some broken servers not
> for all NFSv2 servers.
>
> Anyway that's been fixed in NFSv3, so obviously the "p
Miklos Szeredi wrote:
> The same can be true for tarfs. I mount it for my purpose, others can
> mount it for theirs. Since the daemon providing the filesystem asways
> runs with the same capabilities as the user who did the mount, I and
> others will always get the permissions that we have on the
Miklos Szeredi wrote:
> > Indeed, if it can be done with namespaces _and_ mounting on a file
> > (that file-as-directory concept), _and_ automounting, then you could
> > cd into your tgz files and others could too :)
>
> There's still that little problem of accessing the tgz file both as a
> file
Miklos Szeredi wrote:
> Still can't find it :)
>
> Which kernel? Which file?
I'm looking at linux-2.4.30/fs/nfs/dir.c.
-- Jamie
-
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
Anton Altaparmakov wrote:
> > That said, I would _usually_ prefer that when I enter a tgz, that I
> > see all component files having the same uid/gid/permissions as the tgz
> > file itself - the same as I'd see if I entered a zip file.
>
> As you say _usually_, even you admit that sometimes you wo
> > > A nice implemention of it in FUSE could push it along a bit :)
> >
> > Aren't there some assumptions in VFS that currently make this
> > impossible?
>
> I believe it's OK with VFS, but applications would be confused to death.
> Well, there really is one issue -- dentries have exactly one pa
Miklos Szeredi wrote:
> > > Aren't there some assumptions in VFS that currently make this
> > > impossible?
> >
> > I believe it's OK with VFS, but applications would be confused to death.
> > Well, there really is one issue -- dentries have exactly one parent, so
> > what do you do when opening a
Miklos Szeredi wrote:
> > Look up the rather large linux-kernel & linux-fsdevel thread "silent
> > semantic changes with reiser4" and it's followup threads, from last
> > year.
>
> Wow, it's 700+ messages. I got through the first 40, and already feel
> dizzy :)
It's easier if you skip the ones b
Miklos Szeredi wrote:
> I have a little project to imlement a "userloop" filesystem, which
> works just like "mount -o loop", but you don't need root privs. This
> is really simple to do with FUSE and UML.
That would be a nice way to implement those rarely used old
filesystems that aren't really
Miklos Szeredi wrote:
> > Yet, the results from stat() don't distinguish the number spaces,
> > and "ls" doesn't map the numbers to names properly in the wrong
> > space.
>
> Well you can use "ls -n". It's up to the tools to present the
> information you want in the way you want it. If a tool ca
Eric Van Hensbergen wrote:
> I'd like to second that I think private-namespaces are the right way
> to solve this sort of problem. It also helps not cluttering the
> global namespace with user-local mounts
>
> >
> > Shared subtrees and more support in userspace tools is needed before
> > private
Al Viro wrote:
> Most of the code is already there - do_fork() has to do such stuff anyway.
> So how about adding sys_unshare(flags) that would do that job? Flags would
> correspond to those of clone(2), except that all these guys would be
> "what do we unshare" instead of "what do we leave shared
Al Viro wrote:
> On Wed, Apr 20, 2005 at 10:45:58AM +0100, Jamie Lokier wrote:
> > For FUSE, what's needed is that a user can mount something, and the
> > mounted fs is visible only to that user, but it's visible to _all_ of
> > the user's processes.
>
>
Miklos Szeredi wrote:
> (Please don't post separately to different recipients, that makes
> replying quite awkward. Always reply to all, it's the Right Thing)
>
> > I disagree with this, I think there are plenty of situations where I
> > may want to have several different namespaces for several d
Ram wrote:
> > What we really want is a mount point that propagates across all the
> > processes owned by one user, but is not there for other users.
>
> This is almost certainly bogus. Same user can easily want several
> different environments set on the same box.
Yes of course.
The problem is
Jan Hudec wrote:
> > For FUSE, what's needed is that a user can mount something, and the
> > mounted fs is visible only to that user, but it's visible to _all_ of
> > the user's processes.
>
> Including root's su to that user...
> Keeping information in a process group is the *only* way to actuall
Al Viro wrote:
> On Wed, Apr 20, 2005 at 09:43:47PM +0100, Jamie Lokier wrote:
> > Al Viro is right to point out that environment variables are not
> > shared. But he forgets that _files_ are shared.
>
> So they are. ~/.profile, for instance ;-)
And ~/.cvspass. Mys
Al Viro wrote:
> > If I'm remotely logged into server X from Y, and want to use scp to
> > copy some file from X to Y or vica versa, I will want my private
> > mounts to be visible from the scp.
>
> Do you? Really? OK, so I've got ~/bin/ and ~/bin/arch/ in my path on
> my boxen. The latter has
Jan Hudec wrote:
> By the way, IIRC so far the root can access all kernel memory too via
> /dev/kmem. So the limiting of root's rights would have to be limited
> a bit more yet.
On some hardened systems, root is not allowed access to /dev/kmem.
-- Jamie
-
To unsubscribe from this list: send the l
Jan Hudec wrote:
> On Thu, Apr 21, 2005 at 19:44:56 +0100, Jamie Lokier wrote:
> > Jan Hudec wrote:
> > > By the way, IIRC so far the root can access all kernel memory too via
> > > /dev/kmem. So the limiting of root's rights would have to be limited
> > >
Asser Femø wrote:
> According to the fcntl manual you can cancel a notification by doing
> fcntl(fd, F_NOTIFY, 0) (ie. sending 0 as the notification mask), but
> looking in the kernel code fcntl_dirnotify() immediately calls
> dnotify_flush() with neither telling the vfs module about it. Is there a
Ian Campbell wrote:
> On Tue, 2005-08-23 at 16:23 +0100, Jamie Lokier wrote:
> > ...
> > if (any_dnotify_or_inotify_events_pending) {
> > read_dnotify_or_inotify_events();
> > if (any_events_related_to(file)) {
> > store_in_use
For a while, I've been meaning to bring it up on linux-kernel...
The fsync problem
-----
Chris Wedgwood wrote:
> On Mon, Feb 25, 2008 at 08:50:40PM +, Jamie Lokier wrote:
>
> > On Linux (and other host OSes), fdatsync() and fsync() don't always
> > commit
Jeff Garzik wrote:
> Jamie Lokier wrote:
> >By durable, I mean that fsync() should actually commit writes to
> >physical stable storage,
>
> Yes, it should.
Glad we agree :-)
> >I was surprised that fsync() doesn't do this already. There was a lot
> >of ef
Andrew Morton wrote:
> On Tue, 26 Feb 2008 07:26:50 +0000 Jamie Lokier <[EMAIL PROTECTED]> wrote:
>
> > (It would be nicer if sync_file_range()
> > took a vector of ranges for better elevator scheduling, but let's
> > ignore that :-)
>
> Two passes:
>
Jeff Garzik wrote:
> [snip huge long proposal]
>
> Rather than invent new APIs, we should fix the existing ones to _really_
> flush data to physical media.
Btw, one reason for the length is the current block request API isn't
sufficient even to make fsync() durable with _no_ new APIs.
It offers
Jörn Engel wrote:
> On Tue, 26 February 2008 20:16:11 +1100, Nick Piggin wrote:
> >
> > Yeah, sync_file_range has slightly unusual semantics and introduce
> > the new concept, "writeout", to userspace (does "writeout" include
> > "in drive cache"? the kernel doesn't think so, but the only way to
>
Jörn Engel wrote:
> On Tue, 26 February 2008 20:16:11 +1100, Nick Piggin wrote:
> > Yeah, sync_file_range has slightly unusual semantics and introduce
> > the new concept, "writeout", to userspace (does "writeout" include
> > "in drive cache"? the kernel doesn't think so, but the only way to
> > ma
Ric Wheeler wrote:
> >>I was surprised that fsync() doesn't do this already. There was a lot
> >>of effort put into block I/O write barriers during 2.5, so that
> >>journalling filesystems can force correct write ordering, using disk
> >>flush cache commands.
> >>
> >>After all that effort, I was
Jeff Garzik wrote:
> Nick Piggin wrote:
> >Anyway, the idea of making fsync/fdatasync etc. safe by default is
> >a good idea IMO, and is a bad bug that we don't do that :(
>
> Agreed... it's also disappointing that [unless I'm mistaken] you have
> to hack each filesystem to support barriers.
>
Jörn Engel wrote:
> On Tue, 26 February 2008 15:28:10 +0000, Jamie Lokier wrote:
> >
> > > One interesting aspect of this comes with COW filesystems like btrfs or
> > > logfs. Writing out data pages is not sufficient, because those will get
> > > lost unless t
50 matches
Mail list logo
