On Sat, 10 Apr 1999, Andrea Arcangeli wrote:
On Fri, 9 Apr 1999, Alexander Viro wrote:
The bug of nr_hashed_buffers inconsistency is due where
nr_hashed_buffers++ nr_hashed_buffers-- are been placed by me. They has to
be placed in the path where pprev is != 0. It's really a minor
OK, here is a new version of FAT patch.
Changes:
fixed a couple of races in fs/fat/*.c
fixed a bug in fs/buffer.c that gave massive fs corruption in case
of umount immediately followed by mount for all FAT-derived filesystems.
Now it passes most of Gordon's tests for
Folks, right now we have -lookup() returning 0 in case of success
(in which case the argument gets hashed and becomes either positive or
negative) or a negative integer in case of error (too long name, etc.).
Proposed change: make it return a pointer to struct dentry.
Semantics:
On 18 Apr 1999, Magnus Ahltorp wrote:
Are there any semantic differences in the VFS between 2.2.5 and 2.2.6,
except for d_move() moving from the file system to the VFS?
I've just had reports of strange things happening, but that may well
be because of double d_move:s.
/Magnus
Magnus,
On Mon, 3 May 1999, a sun wrote:
hi all,
i brought this up with bill hawes early last year, but i thought i'd
bring it up again. currently, if you do the obvious things with
d_compare for a case-preserving/case-insensitive filesystem, rename()
doesn't allow you to do a
[Cc'd to fsdevel and to dmsdos maintainers]
On Thu, 15 Jul 1999, Jamie Lokier wrote:
[CRLF conversion] My vote is to kill that feature in 2.3 and retroactively
add a warning to 2.2.11.
FWIW my vote is to kill CRLF conversion too.
Sound reasonable.
OK, folks. Methink I see how to do
[linux-fsdevel added]
On Mon, 6 Sep 1999 [EMAIL PROTECTED] wrote:
It seems, that update_vm_cache was removed old time ago from kernel
(but not from includes), so affs, hfs, ntfs and qnx4 filesystems are
compilable as modules, but unusable.
fixing up hfs is on my todo list. i
On Fri, 8 Oct 1999, Ingo Molnar wrote:
On Fri, 8 Oct 1999, Alexander Viro wrote:
Stephen, Ingo, could you look at the stuff above? Methink it means that we
either must separate ext2_truncate() for directories (doing bforget() on
the data blocks) _or_ put the directory blocks
I began screwing around the truncate() stuff and the following is
a status report/request for comments:
a) call of -truncate() method (and vmtruncate()) had been moved
into the notify_change(). It is triggered if ATTR_SIZE is set. Modified
places: do_truncate(), nfsd_truncate(),
On Mon, 11 Oct 1999, Mikulas Patocka wrote:
I mean the following: assume that call of hpfs_truncate() (via
-truncate()) had been moved into the inode_setattr() (i.e. happens
immediately before the hpfs_write_inode() in hpfs_notify_change()). Will
it have any bad consequences? Right now
On Tue, 12 Oct 1999, Stephen C. Tweedie wrote:
Hi,
On Tue, 12 Oct 1999 09:37:28 -0400 (EDT), Alexander Viro
[EMAIL PROTECTED] said:
Rationale was:
a) get rid of code duplication and get all calls of -truncate()
into the same place.
b) make it in the same place
On Mon, 11 Oct 1999, Stephen C. Tweedie wrote:
Hi,
On Sun, 10 Oct 1999 16:57:18 +0200 (CEST), Andrea Arcangeli
[EMAIL PROTECTED] said:
My point was that even being forced to do a lookup before creating
each empty buffer, will be still faster than 2.2.x as in 2.3.x the hash
will
On Fri, 8 Oct 1999, Manfred Spraul wrote:
Alexander Viro wrote:
All stuff with truncate()/write() is racey right now,
AFAICS. The next thing I'm going to do is a (dumb) implementation of
blocking rwlocks. write() being reader and truncate() - writer.
IMHO that's the wrong approach
On Fri, 8 Oct 1999, Manfred Spraul wrote:
I couldn't find it in the POSIX standart, but at least some UNIXes don't
allow it:
Sure. We are kinda-sorta preventing it too. But there is a windows when
both the shared mmap() and lockf() may pass (if mmap() comes first,
overlaps the memory area
On Wed, 13 Oct 1999, Jeff Garzik wrote:
Some on linux-kernel mentioned that procfs needed cleanup. Is there a
TODO list somewhere?
Even an initial variant of patch (ouch... porting the thing from
2.3.13-pre1 to 2.3.22-pre2 _did_ hurt; damn CVS...).
I can't promise that in the current
Stephen, I've looked through the current stuff with truncate()
(BTW, minixfs is broken too - rmdir() hangs solid) and I think that I have
a more-or-less tolerable solution. You definitely know the VFS/VM
interaction better (I'm mostly dealing with namespace side of the things),
so I'ld
On Mon, 18 Oct 1999, Andrea Arcangeli wrote:
On Sat, 16 Oct 1999, Alexander Viro wrote:
c) Currently we keep the stuff for the first class around the page
cache and the rest in buffer cache. Large part of our problems comes
from the fact that we need to detect migration of block
On Wed, 27 Oct 1999, Jeff Garzik wrote:
Alex,
I now have most of your procfs patch ported to the latest kernels, at
http://gtf.org/garzik/kernel/files/UNTESTED/proc_cleanup_19991026-2.3.24-pre1.patch.gz
Note this is a --cvs patch-- and thus not easily applied by patch.
Thanks. I'll
On Mon, 1 Nov 1999 [EMAIL PROTECTED] wrote:
I agree with this, it feels closer to the linux page cache, the terminology in
the XFS white paper is a little confusing here.
XFS on Irix caches file data in buffers, but not in the regular buffer cache,
they are cached off the vnode and
On Sun, 28 Nov 1999, Manfred Spraul wrote:
Alexander Viro wrote:
I think it's a Bad Thing (tm) that file write operations are single
threaded [generic_file_write() calls down(i_sem)], and I'd like to
change that.
Danger: clashing patches ahead.
I assumed that. If you want
Folks, please help to test it. WARNING: IT'S ON THE CRITICAL PATH
AND IF IT'S BROKEN IT WILL EAT YOUR DATA. SILENTLY. EXTREME DANGER. USE
ONLY ON SCRATCH BOXEN.
Patch merges most of block_write_{partial,cont}_page and fixes a
couple of bad bugs in the latter. It should fix the
On Wed, 1 Dec 1999, Ingo Molnar wrote:
On Tue, 30 Nov 1999, Alexander Viro wrote:
Patch merges most of block_write_{partial,cont}_page and fixes a
couple of bad bugs in the latter. It should fix the problems with
write-beyond-EOF on FAT and HPFS and it cleans the code up
On Thu, 2 Dec 1999, Andrea Arcangeli wrote:
- process can modify the attributes of the file it wants to link
This must be enforced to achieve security (also the very silly quota issue
will be addressed), I agree with you. I agree to change this. I also don't
think the breakage would be
On Fri, 3 Dec 1999, Jeff Garzik wrote:
What needs to be done before the big kernel lock can moved in favor of
the finer-grained inode lock?
knfsd cleanup. SMP-safe dcache. SMP-safe namei.c. And quite a bit of
filesystem code.
On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
I don't need quota for myself either. So? Do you suggest to remove quota
from the kernel because me and you don't need it? You can't just take
decisions for everybody only looking at your needs. Or you should then say
"this system is insecure and
On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
On Fri, 3 Dec 1999, Alexander Viro wrote:
Oh, great. So your reasons should pass for arbitrary filesystem, right?
It's always been so. Sorry if I am been not clear. I was talking about the
VFS not about lowlevel fs. I don't either know why
On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
On Fri, 3 Dec 1999, Alexander Viro wrote:
... and F- on UNIX SA 101 - if you don't know the reasons to keep /tmp on
a separate filesystem.
Would you call this a solution? This is a very ugly workaround. The fact
this works is only a side
On Sun, 12 Dec 1999, Andreas Gruenbacher wrote:
Dear all,
I would like to bring to your attention the current Linux ACL development
efforts. AFAIK, there are two competing implementations:
ACLs for ext2
http://aerobee.informatik.uni-bremen.de/acl_eng.html
Posix ACLs for Linux
On Sun, 12 Dec 1999, Andreas Gruenbacher wrote:
Alexander Viro wrote:
First of all, why do you need the full permissions? Anyway, _if_ you
really need it - that's not a way to go. Really. Minimal solution would go
along the lines
The full permissions are indeed necessary for file
On Mon, 13 Dec 1999, Peter T. Breuer wrote:
Is there a simple way of telling a file system that it needs to revise
its opinion about an inode? I plan to sneak a change underneath on
disk, find the inode it belongs to, and invalidate it.
Is that possible? I've been looking around
Well, since some part of the previous patch went into -pre2...
Variant rediffed against -pre3 is on ftp.math.psu.edu/pub/viro/as-patch-23
News:
added missing SetPageUptodate to NCPFS part (thanks, Petr ;-) and
into AFFS/EFS parts. The rest was OK.
Please, help testing it.
Rediffed against -pre4.
added missing SetPageUptodate to NCPFS part (thanks, Petr ;-) and
into AFFS/EFS parts. The rest was OK.
Still there, it didn't make into -pre3. Submitted, indeed.
New:hopefully correct handling of fast symlinks on UFS. Please, help
testing. Interesting
For the VFS/VM interaction - add mmap()/write() deadlock. BTW, it looks
like FreeBSD has a data-corrupting race almost in the same place...
On Tue, 14 Dec 1999, David S. Miller wrote:
I'm still a few weeks away from getting my platforms working again,
currently I'm wedged at 2.3.27 with some weird perhaps Sparc-specific
issue that is preventing user apps from stating up after boot.
Could be the new zone code, who knows, no
On Wed, 15 Dec 1999, Oliver Neukum wrote:
Hi,
in minixfs the suid bit is not removed, if a file is written to by an ordinary
user. I took the code in question from ext2.
Don't *wham* duplicate *wham* code for no good reasons *wham**wham**wham*
Sorry, but it's Wrong Thing(tm). Correct
On Sat, 8 Jan 2000, Richard B. Johnson wrote:
On Fri, 7 Jan 2000, Alexander Viro wrote:
Folks, there are changes underway in block device interface and
some of them made it into 2.3.38.
[SNIP...]
Good grief Charley Brown! You, in a few key-strokes, just blew away
major portions
[snip the pointer to HFS+ description]
looking therebletch Thanks for the pointer, but... Extremely
disgusting design. Apple: think different, think Vogon... It will be very
hard to do in clean way - current (rather messy) trickery in fs/hfs/* will
not help with arbitrary large amount of forks,
On Thu, 24 Feb 2000, Petr Vandrovec wrote:
On 24 Feb 00 at 9:17, [EMAIL PROTECTED] wrote:
Probably rw_semaphore would be enough - we
could use FOP_GET(file,method) (down for read, returns the method if f_op
is non-NULL, returns NULL otherwise), FOP_PUT(file) (up for read) and
Summary:
1) s_op-notify_change() - went into inode_operations (called
-setattr(), otherwise the same).
2) i_op-default_file_ops - gone. Instead just set -i_fop at the
same time when you set -i_op.
3) init_special_inode() doesn't change -i_op, only -i_fop.
4) in
On Sun, 12 Mar 2000, Peter J. Braam wrote:
Alexander Viro wrote:
6) unions in superblocks (and inodes) are nasty. Use separately-allocated
private parts of either and keep pointer to them in -u.generic_sbp and
-u.generic_ip, resp. It's less critical for superblocks, but for inodes
1) -statfs() changed. Now it takes _kernelspace_ pointer to struct statfs
(and doesn't have to call copy_to_user()). It also expects the buffer filled
with -1's (default value for fields unsupported by filesystem). It _doesn't_
get 'bufsize' argument anymore.
2) vfs_statfs() function is
On Fri, 10 Mar 2000, Erez Zadok wrote:
Thanks Al.
VFS changes are important to any F/S developer, but even more important to
me since my stackable templates must behave like both a lower-level F/S and
a VFS. Ion and I updated our templates to 2.3.49 just a couple of days ago,
taking
1) -read_super() called with lock already taken.
2) module reference counter is taken care of in VFS. Forget about
MOD_{INC.DEC}_USE_COUNT crap in -{read,put}_super().
3) get_fs_type() taken out of the export list. If somebody wants
it back - fine, but I'ld rather _not_ do
On Sat, 11 Mar 2000, Ben Fennema wrote:
Ok, I'm trying to implement streams in UDF.
They are kind of like resource forks/extended attributes.
And our support of 'forks' is a bloody mess (as the whole idea of forks
is - what can you expect from Crapple?). _Please_, wait with it until
the
On Wed, 5 Apr 2000, Erez Zadok wrote:
- if (block_start = to)
- break;
bh-b_end_io = end_buffer_io_sync;
if (!buffer_mapped(bh)) {
err = get_block(inode, block, bh, 1);
And there you go: bloody thing bumps
On Fri, 28 Apr 2000, Andrew Clausen wrote:
Hi all,
Is it possible to have a gap between the super-block and the
start of group 0's metadata? This would be REALLY useful, for:
Yes, but...
[snip]
the first block on the old partition is now the 50.25th block
in the new one. Obviously,
On Mon, 1 May 2000, Richard Gooch wrote:
Alexander Viro writes:
On Mon, 1 May 2000, Richard Gooch wrote:
Eric W. Biederman writes:
Richard Gooch [EMAIL PROTECTED] writes:
Hi, Al. You've previously stated that you consider the multiple
mount feature
On Mon, 1 May 2000, Steve Dodd wrote:
On Mon, May 01, 2000 at 01:41:43AM +0400, Roman V. Shaposhnick wrote:
On Sun, Apr 30, 2000 at 03:28:18PM +0100, Steve Dodd wrote:
But an address_space is (or could be) a completely generic cache. It might
never be associated with an inode, let
On Mon, 1 May 2000, Roman V. Shaposhnick wrote:
2. at the same time can work with stackable or derived ( in C++
terminology ) host objects like file-dentry-inode-phis.
These are _not_ derived in C++ sense. Sorry.
Inode data pages are per-inode, not per-dentry or
On Mon, 1 May 2000, Roman V. Shaposhnick wrote:
On Mon, May 01, 2000 at 01:50:58PM -0400, Alexander Viro wrote:
On Mon, 1 May 2000, Roman V. Shaposhnick wrote:
2. at the same time can work with stackable or derived ( in C++
terminology ) host objects like file
On Tue, 2 May 2000, Chris Mason wrote:
So the reiserfs team has to fix a problem NFS only has when interacting
with reiserfs. Yes, it would have been nice if someone else had the
chance to do it for us, but to expect them to, and to be mad when
they don't, is more than a little silly.
Folks, I've tried to describe the stuff that may IMO become useful
for autofs/devfs/portalfs/etc. Comments are more than welcome.
Current problems:
1. autofs would be much simpler if we had some way to distinguish
between the real negative dentries and
On Wed, 3 May 2000, Jeremy Fitzhardinge wrote:
I'll happily get rid of the tree scanning if there's a better way of doing the
same thing. I don't want to change the basic mechanism of autofs4 right at the
moment though.
OK, then. In practical terms it means that right now autofs4 retains
On Wed, 3 May 2000, Richard Gooch wrote:
I think you're referring here to a "split" devfs, where each driver
exports a mini-devfs. In such an environment, your mount traps would
probably be good.
However, I don't think the mini-devfs idea is a good approach. There
are good reasons for
On Wed, 10 May 2000, Erez Zadok wrote:
IMHO the BSD hacks to libc support unionfs were ugly. To write unionfs,
they used the existing nullfs "template", but then they had to modify the
VFS *and* other user-land stuff.
I was not talking about unionfs. union-mount is pretty different and I
On Mon, 15 May 2000, Linus Torvalds wrote:
On Mon, 15 May 2000, Alexander Viro wrote:
And then there is an issue with multiple mounts - which ones should be
affected by such policy? All of them? The last one? Linus, could you
elaborate on that - what do you actually want here
On Sun, 14 May 2000, Petr Vandrovec wrote:
On Sun, May 14, 2000 at 04:37:46AM -0400, Alexander Viro wrote:
devfs_unlink() does - especially in free_dentries(). Or you can get
your kicks looking at the crap (sorry, Petr, but it _is_ crap - populating
dcache really shouldn't be done
On Mon, 15 May 2000, Petr Vandrovec wrote:
Hi Al,
during last week I decided that I should retry my attempt to add
NCP sessions support into kernel. My last attempts through adding
NCP protocol family ended in some troubles because of connection to
NDS requires connections to couple of
On Sun, 21 May 2000, Alan Cox wrote:
How do you deal with the
poll()
do stuff
poll()
and a directory chage occuring during a 'do stuff' period
Erm... Keeping the time of last poll()-reported event in struct file, for
one? Not that I liked it that much, but IMO it's
On Thu, 25 May 2000, Erez Zadok wrote:
You bring an interesting point, however. With the new multiple mounting and
vfsmount stuff, I hope that we're not re-introducing the same problems that
directory hard-linking caused.
Erez, search the fsdevel archives, will you? Architecture
On Thu, 25 May 2000, Erez Zadok wrote:
Al, since we are now allowing multiple struct vfsmount objects to point to
the same super_block, shouldn't struct super_block have a refcount variable?
In principle - yes. In practice that would require changes to block
device code. I've tried
On Thu, 25 May 2000, Erez Zadok wrote:
For now we're ok, but I think we should consider passing a struct file to
-truncate, and maybe even move -truncate from inode ops to as-ops. Here
are a brief list of reasons:
(1) truncate is fundamentally an operation that is asked to operate on a
Erm... Andrea, could you tell why was -i_count left
non-atomic? Since iput() can be called without the big lock...
Comments?
On Wed, 7 Jun 2000, Andrea Arcangeli wrote:
On Tue, 6 Jun 2000, Alexander Viro wrote:
Erm... Andrea, could you tell why was -i_count left
non-atomic? Since iput() can be called without the big lock...
Comments?
It's not atomic because we have to synchronze the i_count changes
On Sat, 10 Jun 2000, Richard Gooch wrote:
I see your point. However, that suggests that the naming of
/proc/mounts is wrong. Perhaps we should have a /proc/namespace that
shows all these VFS bindings, and separately a list of real mounts.
What's "real"? /proc/mounts would better left as it
On Sat, 10 Jun 2000, Richard Gooch wrote:
What I mean by "real" mounts is a table that shows how each FS was
brought into the namespace (or each namespace, once you implement
CLONE_NEWNS). So for example:
#device filesystem roots
/dev/hda1 ext2/
On Sat, 10 Jun 2000, Richard Gooch wrote:
Will it really make much difference? What would be harder to do
without mount IDs? And how much harder?
Beware of functions with many arguments... Besides, what about "kill
the component of union-mount on /barf NFS-mounted from venus:/foo/bar"?
What
On Tue, 13 Jun 2000, Richard Gooch wrote:
Alexander Viro writes:
On Tue, 13 Jun 2000, Richard Gooch wrote:
So I don't really expect wholesale VFS changes right now (but, hey,
that doesn't seem to stop you getting stuff in;-). But that shouldn't
They would
On Tue, 13 Jun 2000, Richard Gooch wrote:
I'd like to see something more drastic. Indeed, that union crap is by
far the worst offender and needs fixing. But there's a whole pile of
other junk that's just not needed all the time.
Richard, may I remind you that we are supposed to be in the
On Tue, 13 Jun 2000, Richard Gooch wrote:
Yes. And all that time mounting the thing at several point was a huge,
fscking hole.
Sure. And hence RedHat wasn't going to compile it in.
Fine with RedHat, but how in hell does it solve the problem? I don't
_CARE_ for any "party line". I don't
On Fri, 16 Jun 2000, Erez Zadok wrote:
On a related note, since we do have /proc/mounts, and assuming that procfs
is pretty much necessary nowadays, are we going to get rid of /etc/mtab and
completely move all getmntent info into the kernel? I never liked the fact
that people doing mounts
On Fri, 16 Jun 2000, Erez Zadok wrote:
Hey, we can make it yet another ioctl(2). Then we can trade a crapload of
syscalls for a crapload of ioctls --- a time-honored Unix tradition... :-)
:-)
Seriously, an open/read/.../close would work fine, but on what file? If
it's something inside
On Fri, 16 Jun 2000, Richard Gooch wrote:
Alexander Viro writes:
On Fri, 16 Jun 2000, Erez Zadok wrote:
Hey, we can make it yet another ioctl(2). Then we can trade a crapload of
syscalls for a crapload of ioctls --- a time-honored Unix tradition
On Sun, 25 Jun 2000, Richard Gooch wrote:
Hi, Al. Recent kernels have a problem with unmounting via the device
file. If I do:
# mknod /mydev b ...
# mount -n /mydev /mnt
# /tmp/kumount /mydev
Error unmounting: /mydevInvalid argument
This used to work. Note that kumount
[reformatted]
On Mon, 26 Jun 2000, Michael W Zappe wrote:
[snip]
filesystem, CXFS. (originally named Charon, but we discovered two
companies warring over the trademark, and didn't want to touch that with
a 40 foot pole... ;-)
Heh. XFS folks mentioned clustered variant of their puppy. Yup,
On Mon, 24 Jul 2000, Roman Zippel wrote:
Hi,
While trying to get affs working again, I noticed that the current
cont_prepare_write is hardly working, if you write to a file in steps of
1024, the bytes pointer is never updated resulting in an endless loop.
Testcase, please? It certainly
On Mon, 24 Jul 2000, Roman Zippel wrote:
Hi,
While trying to get affs working again, I noticed that the current
cont_prepare_write is hardly working, if you write to a file in steps of
1024, the bytes pointer is never updated resulting in an endless loop.
Testcase, please? It
On Mon, 24 Jul 2000, Pavel Machek wrote:
Hi!
I've been looking at the possibility of cleanly implementing virtual
files (podfuk/avfs style) with the multiple mount thing in 2.4
kernels. Here is how it would work:
1) There needs to be a global lookup hook in VFS. If a real lookup
On Wed, 26 Jul 2000, Daniel Phillips wrote:
Stephen asked me some sharp questions about how this would work,
and after I answered them to his satisfaction he asked me if I
would have time to implement this feature. I said yes, and went
on to write an initial design document describing
On Wed, 26 Jul 2000, Stephen C. Tweedie wrote:
Hi,
On Wed, Jul 26, 2000 at 02:05:11PM -0400, Alexander Viro wrote:
Here is one more for you:
Suppose we grow the last fragment/tail/whatever. Do you copy the
data out of that shared block? If so, how do you update buffer_heads
On Wed, 26 Jul 2000, Daniel Phillips wrote:
If so, how do you update buffer_heads in
pages that cover the relocated data?
We have to be sure that if blocks are buffered then they are buffered in
exactly one place and you always access them through through the buffer hash
table. So
On Wed, 26 Jul 2000, Stephen C. Tweedie wrote:
Hi,
On Wed, Jul 26, 2000 at 02:56:01PM -0400, Alexander Viro wrote:
Not. Data normally is in page. Buffer_heads are not included into buffer
cache. They are refered from the struct page and their -b_data just
points to appropriate
On Wed, 26 Jul 2000, Stephen C. Tweedie wrote:
Hi,
On Wed, Jul 26, 2000 at 02:41:44PM -0400, Alexander Viro wrote:
For tail writes, I'd imagine we would just end up using the page cache
as a virtual cache as NFS uses it, and doing plain copy into the
buffer cache pages
On Wed, 26 Jul 2000, Chris Mason wrote:
In both releases, there is locking on the tail to prevent races, and we
don't bother with tails on files 16k (configurable).
What granularity do you have? (for tail size, that is).
On Thu, 3 Aug 2000, Jeff Garzik wrote:
Neil Brown wrote:
3/ With this patch, only ext2fs can be exported. Naturally when I
submit to Linus, all other filesystems which it makes sense to
export will provide an nfsd_operations structure.
One word: ug.
ug, indeed, but
On Thu, 10 Aug 2000, Daniel Phillips wrote:
Correct me if I'm wrong, but I think that if writepage ever needs to unmerge at
tail then it's an error. The tail should have already been unmerged by the
ext2_file_write, which must necessarily precede the writepage. Similarly for
file_mmap: I
86 matches
Mail list logo
