Re: 2.4.0-test11 ext2 fs corruption

On Tue, 28 Nov 2000, Petr Vandrovec wrote: > Hi Al, > during weekend I was uncompressing XFree (Debian's 4.0.1-7) at home, > with 2.4.0-test11 running on Celeron 300A, 128MB RAM, SMP kernel on up. > It failed to compile lbxproxy/di/main.c. After some investigation I found > that they were ove

Re: 2.4.0-test11 ext2 fs corruption

On Tue, 28 Nov 2000, Petr Vandrovec wrote: > > two ranges? Then it looks like something way below the fs level... Weird. > > Could you verify it with dd? > > Yes, it is identical copy. But I do not think that hdd can write same > data into two places with one command... > > vana:/# dd if=/dev

Re: access() says EROFS even for device files if /dev is mounted RO

On Tue, 28 Nov 2000, Peter Cordes wrote: > I'm of the opinion that Linux should work in the way that is most useful, > as long as that doesn't stop us from running stuff written for other unices. > Unix is mostly good, but parts of it suck. There's no reason to keep the > parts that suck, exc

Re: corruption

On Tue, 28 Nov 2000, Linus Torvalds wrote: > The fact that it is in-core only doesn't mean that much - it could still > easily be just problems at read-time, and if you have an IDE disk I would > strongly suggest you try out the patch that Jens Axboe posted, > re-initializing the "head" pointer

Re: corruption

On Wed, 29 Nov 2000, Tigran Aivazian wrote: > On Wed, 29 Nov 2000, Alexander Viro wrote: > > > > I'ld really like to see details on the box with ext2 corruption on SCSI. > > Tigran, IIRC you had it on SCSI boxen, right? Could you send me relevant > > part of

Re: access() says EROFS even for device files if /dev is mounted RO

On Wed, 29 Nov 2000, Hugh Dickins wrote: > On Tue, 28 Nov 2000, Andries Brouwer wrote: > > On Tue, Nov 28, 2000 at 03:04:31PM +0100, Rogier Wolff wrote: > > > > > Ok, so if you read the standard carefully you get a bogus result. > > > > Why bogus? Things could have been otherwise, but the im

Re: 2.4.0-test11 ext2 fs corruption

On Wed, 29 Nov 2000 [EMAIL PROTECTED] wrote: > > > >--- drivers/block/ll_rw_blk.c~ Wed Nov 29 01:30:22 2000 > >+++ drivers/block/ll_rw_blk.c Wed Nov 29 01:33:00 2000 > >@@ -684,7 +684,7 @@ > >int max_segments = MAX_SEGMENTS; > >struct request * req = NULL, *freereq = NULL;

Re: corruption

On Wed, 29 Nov 2000, Tigran Aivazian wrote: > On Wed, 29 Nov 2000 [EMAIL PROTECTED] wrote: > > > I just tried 2.4.0test12pre3, which has Jens' fix, > > and no corruption to be seen. Will test a bit more, > > but perhaps this did it. > > > > I have also been testing very hard on the SMP (4xXe

Re: access() says EROFS even for device files if /dev is mounted RO

On Wed, 29 Nov 2000, Hugh Dickins wrote: > Sorry, I missed the point at issue here, and what changed when. > Assuming (perhaps wrongly) it's independent of filesystem type, > > Solaris yes ok ok > HP-UX yes EROFS ok > > I don't

Re: access() says EROFS even for device files if /dev is mounted RO

On Wed, 29 Nov 2000, Tigran Aivazian wrote: > All I am saying is that if open on HP/UX allows writing but access denies > it, it is definitely a bug (in HP/UX). Let's remember why access(2) was > invented at all -- to allow setuid-privileged programs to do permission > checks based on real uid

Re: access() says EROFS even for device files if /dev is mounted RO

On Wed, 29 Nov 2000, Tigran Aivazian wrote: > That is precisely the point I was making in my previous email. But both > that email and yours asnwer only one question: > > a) should access(2) behave identical to open(2) (with switched uid)? The > answer is Yes. > > but the main question still

Re: corruption

On Wed, 29 Nov 2000, Tigran Aivazian wrote: > On Wed, 29 Nov 2000, Tigran Aivazian wrote: > > > On Wed, 29 Nov 2000, Linus Torvalds wrote: > > > That still leaves the SCSI corruption, which could not have been due to > > > the request issue. What's the pattern there for people? > > one more t

Re: corruption

On Wed, 29 Nov 2000, Linus Torvalds wrote: > > > On Wed, 29 Nov 2000, Alexander Viro wrote: > > > > Problem fixed by Jens' patch had been there since March, so if it's a > > mix of __make_request() screwing up and something else... Urgh. > > No,

Re: corruption

On Wed, 29 Nov 2000 [EMAIL PROTECTED] wrote: > > ISTR bug reports looking like that and IIRC they were never resolved. > > Have you looked at the report by Daniel Phillips? Yes. The problem is real, but the fix... I'm doing a cleanup there and I'll post the patch when I'll give it some testin

Re: [PATCH] Re: 2.4.0-test11 ext2 fs corruption

On Thu, 30 Nov 2000, Daniel Phillips wrote: > Alexander Viro wrote: > > Bloody hell... > > I don't know if this is the bug he's got, in fact I doubt it, but it's a > bug and it needs fixing. The problem is, ext2_get_group_desc > effectively returns two re

Re: Octal vs. Hex war o' death

On Wed, 29 Nov 2000, Ian S. Nelson wrote: > I'm sure this is a religious issue... but I'm going to suggest it > anyways because I spent a few minutes on it. [snip a boring troll] Could you come up with something more, erm, amusing? - To unsubscribe from this list: send the line "unsubscribe

Re: usbdevfs mount 2x, umount 1x

On Wed, 29 Nov 2000, Randy Dunlap wrote: > [I reported this a couple of months back. Got no > feedback on it. If it's just a DDT (don't do that) > or a user error, please say so.] > > Summary: After I mount usbdevfs 2 times, and umount it > 1 time, the usbcore module use count prevents it f

RE: usbdevfs mount 2x, umount 1x

On Wed, 29 Nov 2000, Dunlap, Randy wrote: > > From: Alexander Viro [mailto:[EMAIL PROTECTED]] > > > > On Wed, 29 Nov 2000, Randy Dunlap wrote: > > > > > [I reported this a couple of months back. Got no > > > feedback on it. If it's just a DD

Re: [PATCH] ext2 largefile fixes + [f]truncate() error value fix

On Sat, 18 Nov 2000, Andrea Arcangeli wrote: [2.2 variant] RLIMIT_FSIZE stuff - vmtruncate(). size < 0 - caller. size > ... - ext2_notify_change(). > if (size >> 33) { ITYM 32 > struct super_block *sb = inode->i_sb; >

Re: [PATCH] ext2 largefile fixes + [f]truncate() error value fix

On Sat, 18 Nov 2000, Andreas Dilger wrote: > Alexander Viro writes: > > * #include removed from ksyms.c. It is not > > needed there (hardly a surprise, since ext2 can be modular itself and > > it doesn't export anything). Ditto for > > * #include remo

Re: [PATCH] ext2 largefile fixes + [f]truncate() error value fix

On Sun, 19 Nov 2000, Andrea Arcangeli wrote: > On Sat, Nov 18, 2000 at 04:55:23PM -0500, Alexander Viro wrote: > > > if (size >> 33) { > >ITYM 32 > > this is a bug in 2.2.x mainstream btw. I don't have recent 2.2 at hand,

Re: corruption

On Thu, 30 Nov 2000, Jonathan Hudson wrote: > > In article <[EMAIL PROTECTED]>, > Andrew Morton <[EMAIL PROTECTED]> writes: > AM> In thread "File corruption part deux", Lawrence Walton wrote: > >> > >> my system has been acting slightly odd on all the pre 12 kernels > >> with the fs goi

[CFT][RFC] ext2_new_inode() fixes and cleanup

* search for appropriate cylinder group had been taken out of the ext2_new_inode() into helper functions - find_cg_dir(sb, parent_group) and find_cg_other(sb, parent_group). Bug caught by Daniel (wrong bh being dirtied when we update the free inodes counter) - fixed. * ext2_new_ino

Re: [CFT][RFC] ext2_new_inode() fixes and cleanup

On Fri, 1 Dec 2000, Andreas Dilger wrote: > Alexander, Ted, > I was taking a hard look at the proposed changes. In load_inode_bitmap() > we shouldn't be cacheing the I/O error case (this was in the old code too). I know. I left it in place since I don't like the idea of putting many not-absol

Re: [CFT][RFC] ext2_new_inode() fixes and cleanup

On Thu, 30 Nov 2000, Theodore Y. Ts'o wrote: > If you could send me the split up, I'd appreciate it, as it'll make it > easier to find any subtle bugs. I certainly like the general way you've > cleaned up the interfaces and factored out the code. See attachments. Order of patches is alphabeti

Re: [PATCH] ext2 largefile fixes + [f]truncate() error value fix

On Sun, 19 Nov 2000, Andrea Arcangeli wrote: > Good spotting but wrong fix. s/32/31/ - forgot about the signedness. And yes, that should go for both 2.2 and 2.4. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please rea

Re: bug in count_open_files() or a strange granularity?

On Tue, 28 Nov 2000, Tigran Aivazian wrote: > On Tue, 28 Nov 2000, David S. Miller wrote: > > What you want is something like: > > > > static int num_open_files(struct files_struct *files, int size) > > { > > total = 0; > > for (i = size / (8 * sizeof(long)); i > 0; ) > > t

Re: bug in count_open_files() or a strange granularity?

On Tue, 28 Nov 2000, David S. Miller wrote: >Date: Tue, 28 Nov 2000 15:13:44 + (GMT) >From: Tigran Aivazian <[EMAIL PROTECTED]> > >I know that there is no problem due to the way it is called in >copy_files() -- it would only be above 32. But for what I want to >use it

Re: ext2 directory size bug (?)

On Sat, 2 Dec 2000, Chris Wedgwood wrote: > On Thu, Nov 30, 2000 at 08:24:02AM -0500, Richard B. Johnson wrote: > > This is actually a feature. The directory does not get truncated. > > Arguably directories could be truncated when objects towards the end > are removed; I believe UFS under

Re: ext2 directory size bug (?)

On Sat, 2 Dec 2000, Chris Wedgwood wrote: > On Sat, Dec 02, 2000 at 12:14:34AM -0500, Alexander Viro wrote: > > Not really. Anything that modifies directories holds both ->i_sem and > ->i_zombie, lookups hold ->i_sem and emptiness checks (i.e. victim in >

RE: usbdevfs mount 2x, umount 1x

On Thu, 30 Nov 2000, Dunlap, Randy wrote: > Yes, that's how it looks to me also, so maybe it's not a kernel > problem. Thanks for the tip. > > Here's more info, including the strace that Al Viro asked for. > I also made sure that I'm using mount & umount version 2.10o. > Please let me know if

Re: corruption

On Sun, 3 Dec 2000, Andrew Morton wrote: > It appears that this problem is not fixed. Sure, it isn't. Place where the shit hits the fan: fs/buffer.c::unmap_buffer(). Add the call of remove_inode_queue(bh) there and see if it helps. I.e. ed fs/buffer.c

Re: corruption

On Sat, 2 Dec 2000, Petr Vandrovec wrote: > Nothing new (was it meant to run remove_inode_queue() conditionaly inside > buffer_mapped() branch? ed did it that way). First is list of buffers at > time of destroy_inode, then process. If you want full oops trace, it is what list of buffers? ->

Re: corruption

On Sat, 2 Dec 2000, Petr Vandrovec wrote: [I wrote:] > > ed fs/buffer.c < > /unmap_buffer/ > > /}/i spin_lock(&lru_list_lock); > > remove_inode_queue(bh); spin_unlock(&lru_list_lock); > > . > > wq > > EOF Damn. I claim the sudden idiocy attack - did

Re: /dev/random probs in 2.4test(12-pre3)

On Sat, 2 Dec 2000, Theodore Y. Ts'o wrote: > particularly people who writing network programs. The number of people > who assume that they can get an entire (variable-length) RPC packet by > doing a single read() call astounds me. TCP doesn't provide message > boundaries, never did and never

Re: [PATCH] removal of "static foo = 0"

On Tue, 28 Nov 2000, Andrea Arcangeli wrote: > On Tue, Nov 28, 2000 at 12:10:33PM +0900, [EMAIL PROTECTED] wrote: > > If you have two files: > > test1.c: > > int a,b,c; > > > > test2.c: > > int a,c; > > > > Which is _stronger_? > > Those won't link together as they aren't declared static. T

Re: [PATCH] ext2 largefile fixes + [f]truncate() error value fix

On Sun, 19 Nov 2000, Alan Cox wrote: > > is probably in order. Alan? Place in question is the check for notify_change() > > growing the file past 4Gb - it should check for size >> 32, obviously. > > The 2.2 limit is 2Gbytes Sorry. - To unsubscribe from this list: send the line "unsubscribe

Re: bug in count_open_files() or a strange granularity?

On Tue, 28 Nov 2000, Tigran Aivazian wrote: >/* switch the open fds from old_user to new_user */ > read_lock(&files->file_lock); > nr_open = close_files(files, 0); /* 0 means don't close them */ > atomic_sub(nr_open, &old_user->files); > atomic_add(nr_ope

Re: bug in count_open_files() or a strange granularity?

On Tue, 28 Nov 2000, Tigran Aivazian wrote: > it is not basic at all. The problems you point out are extremely complex > (at least the fd in transit issue, definitely is). > > So, yes it requires a bit more thought. I will come back when the issues > you pointed out are dealt with. Someone ha

Re: [PATCH] ext2 largefile fixes + [f]truncate() error value fix

On Sat, 18 Nov 2000, Alexander Viro wrote: > On Sun, 19 Nov 2000, Alan Cox wrote: > > > > is probably in order. Alan? Place in question is the check for notify_change() > > > growing the file past 4Gb - it should check for size >> 32, obviously. > > >

[CFT][PATCH] write() fixes.

Folks, the patch below is a combination of -EFBIG fixes posted yesterday with _very_ preliminary stuff that deals with behaviour of write() in cases when get_block() fails. It compiles, but that's about all I can really promise. Please, give it a try. It should be reasonably safe (

[resync?] Re: corruption

On Mon, 4 Dec 2000, Andrew Morton wrote: > Sorry, it's still failing. It took three hours. Yes. For one thing, original was plain wrong wrt locking (lru_list_lock should be held). For another, it does not take care of metadata. And that's way more serious. What really happens: ext2_truncate(

[PATCH] inode dirty blocks Re: test12-pre4

On Sun, 3 Dec 2000, Linus Torvalds wrote: > > Synching up with Alan and various other stuff. The most important one > being the fix to the inode dirty block list. It doesn't solve the problem. If you unlink a file with dirty metadata you have a nice chance to hit the BUG() in inode.c:83. I ho

Re: [PATCH] inode dirty blocks

OK, guys, I think I've got it: static int ext2_update_inode(struct inode * inode, int do_sync) { ... mark_buffer_dirty_inode(bh, inode); ... } Yes, that's right. bh of piece of inode table is put on inode's list. Fix: in ext2/inode.c 1211s/mark_buffer_dirty_inode/

Re: corruption

On Mon, 4 Dec 2000, Stephen C. Tweedie wrote: > unmap_buffer() calls mark_buffer_clean() calls refile_buffer() calls > remove_inode_queue(), which is why we don't see this all the time. Not enough, since you can hit the window between the request completion (bh is marked clean) and getting it

Re: [PATCH] Attempt to hard link across filesystems results inun-unmountable filesystem (fwd)

On Mon, 4 Dec 2000, Tigran Aivazian wrote: > It is true that your patch fixes the problem as reported but let us look > one step deeper into the problem. Linux supports multiply mounted > instances of a filesystem and the check in sys_link() comparing the > mountpoints would refuse (with cross-

Re: [PATCH] inode dirty blocks Re: test12-pre4

On Mon, 4 Dec 2000, Stephen C. Tweedie wrote: > Agreed. However, is there any reason to have this as a separate > function? bforget() should _always_ remove the buffer from any inode > queue. You can make that operation conditional on (bh->b_inode != > NULL) if you want to avoid taking the l

Re: [PATCH] inode dirty blocks

On Mon, 4 Dec 2000, Linus Torvalds wrote: > > > On Tue, 5 Dec 2000, Andrew Morton wrote: > > > > - test12-pre4 > > - aviro bforget patch > > Is the bforget patch really needed? > > If clear_inode() gets rid of dirty buffers, I don't see how new dirty > buffers can magically appear

Re: test12-pre5

On Mon, 4 Dec 2000, Linus Torvalds wrote: > > Ok, this contains one of the fixes for the dirty inode buffer list (the > other fix is pending, simply because I still want to understand why it > would be needed at all). Al? See previous posting. BTW, -pre5 doesn't do the right thing in clear_in

Re: [PATCH] inode dirty blocks

On Mon, 4 Dec 2000, Linus Torvalds wrote: > I just wanted to be clear on the purpose of the patches. The bforget() one > looks like "taking care of the details", but not like a bug-fix. Agreed? Agreed - invalidate_inode_buffers() seems to be doing the right thing, so previous objections do not

Re: test12-pre5

On Mon, 4 Dec 2000, Linus Torvalds wrote: > So? Why wouldn't clear_inode() get rid of it? It will. Mea culpa. However, other reasons for taking the bh of freed block from the list still stand. IOW, consider that part as an optimization. - To unsubscribe from this list: send the line "unsubscr

Re: test12-pre5

On Tue, 5 Dec 2000, Stephen C. Tweedie wrote: > That is still buggy. We MUST NOT invalidate the inode buffers unless > i_nlink == 0, because otherwise a subsequent open() and fsync() will > have forgotten what buffers are dirty, and hence will fail to > synchronise properly with the disk. Cor

Re: test12-pre5

On Tue, 5 Dec 2000, Linus Torvalds wrote: > Get your acts together, guys. Stop blathering and frothing at the mouth. > The only time clear_inode() should be called is (a) when we prune the > inode cache - and we CLEARLY cannot prune an inode if it still has dirty > blocks associated with it and

Re: test12-pre5

On Tue, 5 Dec 2000, Linus Torvalds wrote: > > So Stephen is right wrt fsync() (it will not get that stuff on disk). > > However, it's not a bug - if that crap will not end up on disk we > > will only win. > > Stephen is _wrong_ wrt fsync(). > > Why? > > Think about it for a second. How the h

Re: check_lock() in d_move() and switch_names()?

On Tue, 5 Dec 2000, Tigran Aivazian wrote: > Hi, > > The check for BKL in d_move() and switch_names() seem to be unnecessary as > d_move() takes dcache_lock and switch_names() is only called by > d_move(). So, if the callers take BKL just for the sake of d_move() they > do not need to, but if,

Re: check_lock() in d_move() and switch_names()?

On Tue, 5 Dec 2000, Tigran Aivazian wrote: > Alexander, in one point at least you are wrong. That one point is -- I did > _not_ suggest any optimizations (especially microoptimizations). I was > merely trying to see exactly _why_ d_move() needs a BKL since it takes > dcache_lock which already p

Re: test12-pre5

On Tue, 5 Dec 2000, Linus Torvalds wrote: > And this is not just a "it happens to be like this" kind of thing. It > _has_ to be like this, because every time we call clear_inode() we are > going to physically free the memory associated with the inode very soon > afterwards. Which means that _an

Re: test12-pre6

On Tue, 5 Dec 2000, Linus Torvalds wrote: > > Ok, I almost called this the final test12, but I wanted to get some more > feedback on the keyboard controller stuff and PCI irq routing. Linus, could you apply the following bunch of fixes (split into separate emails): * dentry leak upon

[PATCH] Re: test12-pre6

ext2_update_inode() marks the filesystems as having large files if there the file becomes too large for old driver (2.2 one). Unfortunately, it gets the limit wrong - it's not 2^32, it's 2^31. So we should check for ->i_size_high being non zero _or_ ->i_size having bit 31 set. Please, appl

[PATCH] Re: test12-pre6

If get_block() fails in block_prepare_write() we should zero the blocks we've allocated and mark them dirty. We don't (i.e. we leave the random junk in file in that case). Fix: do it. Moreover, if ->prepare_write() fails generic_file_write() is not going to write the user's data into that

[PATCH] Re: test12-pre6

truncate() and ftruncate() return values are different from the POSIX requirements and from the values returned by other Unices (and from our own manpages, BTW). Trivial fix follows. Rationale: see truncate(2), ftruncate(2), POSIX or try to call the thing on other Unices. Please,

[PATCH] Re: test12-pre6

ext2_get_block() should return -EFBIG if the block number is too large for our block size. It returns -EIO and prints a warning right now. Fix: don't generate bogus warnings (we can legitimately get larger-than-maximum arguments; there is no way in hell VFS or VM could know the ext2-specif

Re: [PATCH] Re: test12-pre6

On Wed, 6 Dec 2000, Tigran Aivazian wrote: > On Wed, 6 Dec 2000, Tigran Aivazian wrote: > > error = -EPERM; > > if (IS_IMMUTABLE(inode) || IS_APPEND(inode)) > > goto dput_and_out; > > also, while we are here -- are you sure that EPERM is a good idea for > IS_IMMUTABLE(inode

Re: [patch-2.4.0-test12-pre6] truncate(2) permissions

On Wed, 6 Dec 2000, Linus Torvalds wrote: > > > On Wed, 6 Dec 2000, Tigran Aivazian wrote: > > > > This patch combines your previous patch with 2 changes I have just > > suggested. Both changes are obvious (and correct). > > Why remove the EROFS test? Tigran has a point - permission() does

Re: [patch] Re: [patch-2.4.0-test12-pre6] truncate(2) permissions

On Thu, 7 Dec 2000, Tigran Aivazian wrote: > The rationale for being compatible with 4.4BSD on append-only but not on > immutable is -- for immutable we can do the test by means of permission() > fast but for append-only we would need an extra if() above permission so > let's just be BSD-compat

Re: [patch] Re: [patch-2.4.0-test12-pre6] truncate(2) permissions

On Thu, 7 Dec 2000, Tigran Aivazian wrote: > yet. So far you only said that a different implementation, i.e. a > different place to put the checks, is preferrable. -EPERM returned by permission() if we ask for write access to immutable. Al, currently walking through the /usr/share/man/man2 an

Re: getcwd() returning -ENOENT???

On Thu, 7 Dec 2000, Russell King wrote: > Hi, > > Can someone explain why I'm seeing the following on test12-pre7: > > bash# /bin/pwd > /bin/pwd: cannot get current directory: No such file or directory Directory is unhashed. Normally it means that sucker had been deleted. > bash# vdir /proc

Re: SUID Patent (was RE: SCO: "thread creation is about a thousandti mes faster than on)

On Tue, 29 Aug 2000, Marty Fouts wrote: > > Unfortunately, you are incorrect. DMR did receive a US Patent (Patent > #4135240) on the SUID bit. There is at least on text on Unix security that > contains a copy of the patent in an appendix. "Didn't happen" was about "and refuse to license" bi

Re: hfs support for blocksize != 512

On Tue, 29 Aug 2000, Matthew Wilcox wrote: > On Tue, Aug 29, 2000 at 06:08:04PM +0200, Roman Zippel wrote: > > Anyway, I'm happy about any bug reports, that you can't reproduce with > > hfs on a drive with 512 byte sectors (for that I still trying to fully > > understand hfs btrees :-) ). I don

Re: hfs support for blocksize != 512

On Tue, 29 Aug 2000, Roman Zippel wrote: > hfs. For example reading from a file might require a read from a btree > file (extent file), with what another file write can be busy with (e.g. > reordering the btree nodes). And? > I really would prefer that a fs could sleep _and_ can use semaphore

Re: hfs support for blocksize != 512

On Wed, 30 Aug 2000, Roman Zippel wrote: > > > hfs. For example reading from a file might require a read from a btree > > > file (extent file), with what another file write can be busy with (e.g. > > > reordering the btree nodes). > > > > And? > > The point is: the thing I like about Linux is

Re: hfs support for blocksize != 512

On Tue, 29 Aug 2000, David A. Gatwood wrote: > Indeed, that's what a VFS layer should do -- abstract away all physical > structure, inodes, etc., leaving only the file abstraction. I've read It does. That leaves caring about the internal structures to fs - you don't want fscked block bitmap o

Re: hfs support for blocksize != 512

On Wed, 30 Aug 2000, Albert D. Cahalan wrote: > Ext2, XFS, Reiserfs, NWFS, and JFS need a multi-threaded VFS. > Do we really need a screaming fast multi-threaded AFFS driver? Erm... Roman seems to complain about VFS/VM not locking hard enough to make protection of private fs data structures un

Re: hfs support for blocksize != 512

On Wed, 30 Aug 2000, Roman Zippel wrote: > VFS isn't really wrong, the problem is that it moved from an almost > single threaded API to a multithreaded API and that development isn't > complete yet. Sorry, it's a complete bullshit. VFS had been multi-threaded from the very beginning. You are con

Re: hfs support for blocksize != 512

On Wed, 30 Aug 2000, Roman Zippel wrote: > No, I didn't say that. I want the API to be less restrictive and make > the job for the fs a bit easier. IMO the current API is inconsistent > and/or incomplete and I'm still trying to find out what exactly is > missing. The VFS is becoming more and mo

Re: hfs support for blocksize != 512

On Wed, 30 Aug 2000, Roman Zippel wrote: > > Your repeated claims of VFS becoming more multi-threaded in ways > > that are not transparent to fs drivers wrt locking are false. > > For example the usage of inode lock changed pretty much and was partly > replaced with the page lock? I can st

Re: [PATCH] thread wakeup fix for 2.4.0-test7

On Thu, 31 Aug 2000, Jamie Lokier wrote: > Alan Cox wrote: > > > close doesn't close. This would be a ``bug'', Linus. > > > > Nope. The fd can be closed and a new one opened while the poll sleeps on the > > existing one. The current code is compliant > > So can you open enough files to crash

Re: hfs support for blocksize != 512

On Thu, 31 Aug 2000, Roman Zippel wrote: > Disclaimer: I know that the following doesn't match the current > implementation, it's just how I would intuitively would do it: > > - get dentry foo > - get dentry baz How? OK, you've found block of baz. You know the name, all right. Now you've got

Re: hfs support for blocksize != 512

On Thu, 31 Aug 2000, J. Dow wrote: > > being a jaded bastard I suspect that Commodore PHBs decided to save a > > bit on floppy controller price and did it well after the initial design > > Comododo PHBs had nothing to do with it. And the Commododo floppy > disk format is quite literally unread

Re: hfs support for blocksize != 512

[snip the plans for AFFS] You know what? Try it. If your scheme is doable at all (I _very_ seriously doubt it, since I've seen similar attempts on FAT-derived filesystems and I remember very well what horror it was) it is doable with private locks. Just take your locks always after the VFS is do

Re: hfs support for blocksize != 512

On Thu, 31 Aug 2000, J. Dow wrote: > > Ouch... Why did he do them (links to directories, that is), in the > > first place? > > Since you asked, but I am warning you that you don't want to know > Well, maybe you do - there is a project to port UNIXy tools to every > platform in existance. W

Re: 512 byte magic multiplier (was: Large File support and blocks)

On Fri, 1 Sep 2000, Daniel Phillips wrote: > Linda Walsh wrote: > > It may not matter too too much, but blocks are being passed around as > > 'ints'. On the ia32 architecture, this implies a maximum of 512*2G->1T > > disk size. Probably don't need to worry about this today, but in a few > > y

Re: thread group comments

On Fri, 1 Sep 2000, Linus Torvalds wrote: > Oh, I basically agree, _except_ that Al Viro has these ideas pending for > 2.5.x that basically create a "process capability cache" that is a cache > of all the process ID's and capabilities (ie uid, gid, groups etc). Which > would be this copy-on-wri

Re: [patchlet] Removing unneeded line in vmtruncate() (2.4.0-t8p1)

On Fri, 1 Sep 2000, Tigran Aivazian wrote: > Rasmus, you introduced a bug because you removed the code but left the > comment around. now /* this should go into ->truncate */ is there and very > confusing - what should go into ->truncate? ... except that comment is there for purpose. Expanding

Re: thread rant

On Sat, 2 Sep 2000, dean gaudet wrote: > the thread bashing is mostly bashing programs which do things such as a > thread per-connection. this is the most obvious, and easy way to use > threads, but it's not necessarily the best performance, and certainly > doesn't scale. (on the scalability

Re: thread rant

On Sat, 2 Sep 2000, Ingo Molnar wrote: > well, Linux SysV shared memory indeed has a 'software version' of > pagetables, this way if one process faults in a new page (because all > pages are unmapped originally), then the new physical page address can be > discovered by all other subsequent fau

Re: [patchlet] Removing unneeded line in vmtruncate() (2.4.0-t8p1)

On Sat, 2 Sep 2000, Rasmus Andersen wrote: > > ... except that comment is there for purpose. Expanding ->truncate() > > should not set ->i_size until it's done with the metadata. You don't want > > mappings on the part currently being expanded. It doesn't matter for ext2 > > and friends, but it

Re: thread rant

On Sat, 2 Sep 2000, Jamie Lokier wrote: > dean gaudet wrote: > > an example of brokenness in the traditional fd API is close-on-exec -- > > there's a race between open()/socket()/pipe() and fcntl(FD_CLOEXEC) during > > which if another thread does a fork() it's possible the child will inherit >

Re: hfs support for blocksize != 512

On Sat, 2 Sep 2000, Roman Zippel wrote: > Hi, > > On Thu, 31 Aug 2000, Alexander Viro wrote: > > > Go ahead, write it. IMNSHO it's going to be much more complicated and > > race-prone, but code talks. If you will manage to write it in clear and > > rac

Re: thread rant

On Sat, 2 Sep 2000, Ingo Molnar wrote: > > On Sat, 2 Sep 2000, Alexander Viro wrote: > > > Why? I would say that bad thing about SysV shared memory is that it's > > _not_ sufficiently filesystem-thing - a special API where 'create a > > file on ramfs and

Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VMnow?

On Sat, 2 Sep 2000, Linus Torvalds wrote: > > 1) the innd data corruption bug > > This, I think, was due to a bug in ext2 truncate. If so, it should be > fixed in test8-pre2. Ted had ACKed the previous chunk of truncate changes, so that one will go immediately once the -pre2 is on ftp.kernel

Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VMnow?

On Sat, 2 Sep 2000, Alexander Viro wrote: > IOW, bug in question _does_ give the same kind of behaviour, but whether > innd is hitting it or something different that happens to act like that... > The only way to know is to try it. > > I'll send rediffed patch in half an

Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VMnow?

On Sat, 2 Sep 2000, Linus Torvalds wrote: > You don't actually have to be smart. > > There's a really simple way to avoid this: compare the thing you're going > to zero out against zero before you memset() it to zero. If it was already > zero, you just unlock the page and release. > > Downsi

Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VMnow?

On Sat, 2 Sep 2000, Linus Torvalds wrote: > > > On Sun, 3 Sep 2000, Alexander Viro wrote: > > > > > > Comments? Basically the "grab_cache_page()" would be a "read_cache_page()" > > > instead with all the wait-on-page etc stuff. >

Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VMnow?

On Sat, 2 Sep 2000, Linus Torvalds wrote: > Not at all. In fact, I'd prefer it that way, because this same thing is > obviously going to be useful for any other block filesystem with the same > issue. Which is a nice way to say "any other block filesystem in the tree" ;-/ Oh, well... Modulo ->

Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VMnow?

On Sun, 3 Sep 2000, [iso-8859-1] Henrik Størner wrote: > On Sat, Sep 02, 2000 at 01:58:58PM -0700, Linus Torvalds wrote: > > [ext2 truncate bug which caused the innd file corruption may > also affect other filesystems] > > > Anyway, the way to test if you have the bug is this simple program

Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VMnow?

On Sun, 3 Sep 2000, Alexander Viro wrote: > OK, after a bit of thinking it looks like we'll need slightly different > prototype. How about the following? BTW, mem_is_zero() really asks for > inclusion into string.h, IMO. Arrgh. Sorry about that mess. Corrected variant: diff

Re: test8-pre2 fs corruption?

On Sun, 3 Sep 2000, Mohammad A. Haque wrote: > Hello > > Alot of my mailboxes have become corrupt after trying test8-pre2. I'm > back down to test7 and everything seems to be working ok so far. I was > able to forcibly corrupt a couple of mailboxes by reading unread mail > from about a week or

Re: test8-pre2 fs corruption?

On Sun, 3 Sep 2000, Thomas Molina wrote: > On Sun, 3 Sep 2000, Mohammad A. Haque wrote: > > > Hello > > > > Alot of my mailboxes have become corrupt after trying test8-pre2. I'm > > back down to test7 and everything seems to be working ok so far. I was > > able to forcibly corrupt a couple of

Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VMnow?

On Sun, 3 Sep 2000, Rik van Riel wrote: > On Sat, 2 Sep 2000, Linus Torvalds wrote: > > On Sat, 2 Sep 2000, Rik van Riel wrote: > > > > 1) the innd data corruption bug > > > > This, I think, was due to a bug in ext2 truncate. If so, it > > should be fixed in test8-pre2. > > Cool... Unfortun

<    1   2   3   4   5   6   7   8   9   10   >