Re: Race in iput()

2000-06-12 Thread Andrea Arcangeli
On Wed, 7 Jun 2000, Alexander Viro wrote: 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

Re: Race in iput()

2000-06-08 Thread Andrea Arcangeli
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 with the list changes (see __iget), so making it

Re: [linux-audio-dev] Re: File writes with O_SYNC slow

2000-04-21 Thread Andrea Arcangeli
On Thu, 20 Apr 2000, Stephen C. Tweedie wrote: much difference, and it may be the stick we need to beat Linus into believing that this change is really quite important. The change is really quite important and it will return to be important as it was importnat in 2.2.x when raid5 will work

Re: elevator BUG()

2000-04-02 Thread Andrea Arcangeli
On Sun, 2 Apr 2000, Andrew Morton wrote: Should this also be applied to 2.2.15? Not mandatory. It's not a must to set nr_segments to zero (also in 2.3.x). But the elevator debugging code to better check that none regular request can sit on the queue with req-q == NULL also assumes special

Re: elevator BUG()

2000-04-01 Thread Andrea Arcangeli
On Sat, 1 Apr 2000, Andrew Morton wrote: A week of two back I was discussing a couple of elevator hiccups with Andrea. I have now found a way to reproduce them. /bin/sync. mnm:/usr/src/linux alias make="make -j3" mnm:/usr/src/linux while true ; do sync ; sleep 15 ; done mnm:/usr/src/linux

Re: elevator BUG()

2000-04-01 Thread Andrea Arcangeli
On Sat, 1 Apr 2000, Manfred Spraul wrote: From: "Andrea Arcangeli" [EMAIL PROTECTED] And the previous one (as said in earlier email) made no sense since 16:06 should be the sixth gscd and you said you don't have such device even compiled into the kernel. Perhaps the debug c

Re: elevator BUG()

2000-04-01 Thread Andrea Arcangeli
On Sun, 2 Apr 2000, Andrew Morton wrote: Wow. I hadn't spotted that 'counter % 100'. They're spewing out now, even without 'sync' I've attached here one for device 21:05 (aka 33:05, aka /dev/hde5) Here the fix: --- 2.3.99-pre4-pre2aa/drivers/ide/ide.c.~1~Mon Mar 27 22:44:47 2000 +++

Re: file system size limits

2000-01-10 Thread Andrea Arcangeli
On Mon, 10 Jan 2000, Theodore Y. Ts'o wrote: No. It's not an ext2 problem, and it's bad form to put safety checks at the wrong layer. Invariably, that sort of magic test never gets Agreed. You can put safety checks in in the kernel level of MD, and in the MD software tools; that should

Re: file system size limits

2000-01-10 Thread Andrea Arcangeli
On Mon, 10 Jan 2000, Theodore Y. Ts'o wrote: There may be an issue for some block device drivers that might use 512 byte sectors (such as IDE disks) on a 32-bit system, but that won't be an problem if you're using an MD device to put together the disks for the 2TB filesystem. Wrong, because

Re: file system size limits

2000-01-10 Thread Andrea Arcangeli
On Mon, 10 Jan 2000, Tigran Aivazian wrote: I am sorry to be "picking" but 2^32*512 bytes is not 2048 T, it is not even 2.1T but a mere 2T. Sorry, I am always been bad in doing math calcs :) Andrea

Re: file system size limits

2000-01-10 Thread Andrea Arcangeli
On Mon, 10 Jan 2000, Manfred Spraul wrote: 2^32 * 512 == 2^32 * 2^9 == 2^^41 2^10 kilo 2^20 mega 2^30 giga 2^40 terra --- 2^^41 == 2 terrabyte. Yes, so it's an issue also for ext2. Anyway all my emails still apply, with the difference that the probabily to hit the bug increases. I

Re: file system size limits

2000-01-10 Thread Andrea Arcangeli
On Mon, 10 Jan 2000, Manfred Spraul wrote: Now the RAID tools MUST NOT mount the 4 TB disk array, or you'll destroy your data. [the calculation bh[i]-b_rsector = bh[i]-b_blocknr*(bh[i]-b_size9); in ll_rw_blk.c would overflow] Why? rsector is a multiple of 512bytes of course. But rsector

Re: file system size limits

2000-01-07 Thread Andrea Arcangeli
On Fri, 7 Jan 2000, Manfred Spraul wrote: eg it seems that lvm doesn't contain the checks for lvm's 2 TB on 32-bit platforms. Actually lvm has real issues as well. When the real issues will gets fixed we'll add the avoid-admin-to-do-silly-things checks too :). Andrea

Re: file system size limits

2000-01-06 Thread Andrea Arcangeli
On Thu, 6 Jan 2000, Manfred Spraul wrote: I agree that ext2 would support 8TB with 4K blocks, but the block device drivers don't support that. Andi infact never talked about i386. Andrea

Re: RFC: Re: journal ports for 2.3?

1999-12-27 Thread Andrea Arcangeli
On Tue, 21 Dec 1999, Benjamin C.R. LaHaise wrote: The buffer dirty lists are the wrong place to be dealing with this. We The only reason for not using buffer.c is to make sure to not insert bugs in such file. need a lightweight, fast way of monitoring the system's dirty buffer/page The

Re: RFC: Re: journal ports for 2.3?

1999-12-21 Thread Andrea Arcangeli
On Tue, 21 Dec 1999, Stephen C. Tweedie wrote: refile_buffer() checks in buffer.c. Ideally there should be a system-wide upper bound on dirty data: if each different filesystem starts to throttle writes at 50% of physical memory then you only need two different filesystems to

Re: (reiserfs) Re: RFC: Re: journal ports for 2.3?

1999-12-21 Thread Andrea Arcangeli
On Tue, 21 Dec 1999, Stephen C. Tweedie wrote: We cannot use the buffer.c dirty list anyway because bdflush can write those buffers to disk at any time. Transactions have to control the So you are talking about replacing this line: dirty = size_buffers_type[BUF_DIRTY] PAGE_SHIFT;

Re: Can't hardlink in different dirs. (BUG#826)

1999-12-05 Thread Andrea Arcangeli
On Sun, 5 Dec 1999, Alexander Viro wrote: The whole point being that _nobody_ has it opened. It was attached to a packet when sender called sendmsg(). That is, set of descriptors passed by caller of sendmsg() had been converted into the set of struct file * When recvmsg() is called by the

Re: Can't hardlink in different dirs. (BUG#826)

1999-12-03 Thread Andrea Arcangeli
On Fri, 3 Dec 1999, Richard Gooch wrote: What? Having group write on the directory? No thanks. You can't hardlink a directory. I'll tell another way that will let you understand correctly for sure. I want that the i_link of an inode can be changed only by an user that has write permissions on

Re: Can't hardlink in different dirs. (BUG#826)

1999-12-03 Thread Andrea Arcangeli
On Fri, 3 Dec 1999, Alexander Viro wrote: Andrea, you _do_ realize that CODA is not a Linux-only thing? So it's Have I ever talked about coda in first place? Andrea

Re: Can't hardlink in different dirs. (BUG#826)

1999-12-03 Thread Andrea Arcangeli
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 effect of the limitations of the hardlink. So another

Re: Can't hardlink in different dirs. (BUG#826)

1999-12-02 Thread Andrea Arcangeli
On Thu, 2 Dec 1999, Alexander Viro wrote: such games link() is the least of your problems - it's effect can be completely reproduced with plain open(). exec 42/bar/foo and several hours after that sh -c /dev/fd/42 will do the trick - fork() preserves open descriptors. If there was really a

Re: coda lock-up in 2.3.29

1999-11-29 Thread Andrea Arcangeli
On Sun, 28 Nov 1999, Manfred Spraul wrote: for(;;){ read(fd,data,sizeof(data)); if(EOF) break; process_data(data); } Do you know if we have to ensure that no record is returned twice, no record is missed? I just checked the POSIX standard, but I found

Re: [RFC] Per-inode metadata cache.

1999-10-18 Thread Andrea Arcangeli
On Mon, 18 Oct 1999, Alexander Viro wrote: ? The same way you are doing it with pagecache. I think if I would have just understood I wouldn't be asking here ;). WTF would we _need_ to know? Think about it as about memory caching. You can cache by virtual address and you can cache by physical

Re: [RFC] Per-inode metadata cache.

1999-10-18 Thread Andrea Arcangeli
On Mon, 18 Oct 1999, Stephen C. Tweedie wrote: Data and metadata are completely different. On, say, a large and busy web or ftp server, you really don't care about a 1G metadata limit, but a 1G page cache limit is much more painful. Sure I completly agree. It looked you was talking about

Re: [patch] [possible race in ext2] Re: how to write get_block?

1999-10-12 Thread Andrea Arcangeli
On Tue, 12 Oct 1999, Stephen C. Tweedie wrote: changes. The ext2 truncate code is really, really careful to provide I was _not_ talking about ext2 at all. I was talking about the bforget and brelse semantics. As bforget fallback to brelse you shouldn't expect bforget to really destroy the

Re: [patch] [possible race in ext2] Re: how to write get_block?

1999-10-12 Thread Andrea Arcangeli
On 11 Oct 1999, Eric W. Biederman wrote: What about adding to the end of ext2_alloc_block: It's _equally_ slow. Do you seen my patch? I prefer to do the query at the higher lever to save cpu cache. Andrea

Re: [patch] [possible race in ext2] Re: how to write get_block?

1999-10-12 Thread Andrea Arcangeli
On Tue, 12 Oct 1999, Stephen C. Tweedie wrote: Umm, your last proposal was to do a hash lookup on each new page cache buffer mapping. That is a significant performance cost, which IMHO is not exactly the right direction either. :) It's not obvious that the only thing to consider are

Re: [patch] [possible race in ext2] Re: how to write get_block?

1999-10-09 Thread Andrea Arcangeli
On Fri, 8 Oct 1999, Mikulas Patocka wrote: Here goes quick'n'dirty patch. It does bforget(). It should prevent file corruption. wrong patch. bforget give you no guarantee at all. bfoget always fallback to brelse if necessary. What I said about bforget in my old email is still true. The _only_

Re: [patch] ramdisk blocksize

1999-08-22 Thread Andrea Arcangeli
On Sat, 21 Aug 1999, Bradley D. LaRonde wrote: but booting with initrd gives the following error (then goes on, apparently working fine): Hmm... probably I missed something specific to initrd (I have not tried it myself btw). I'll have a look at it now. does not get the error. dd'ing an image

Re: [RFC] set_blocksize() oddity.

1999-04-10 Thread Andrea Arcangeli
-unlinking stuff on a page that you are asking to go in the freelist. Andrea Arcangeli

Re: [RFC] set_blocksize() oddity.

1999-04-09 Thread Andrea Arcangeli
; if (next) { bh-b_next = next; next-b_pprev = bh-b_next; } *bhp = bh; bh-b_pprev = bhp; nr_hashed_buffers++; } Andrea Arcangeli

Re: [RFC] set_blocksize() oddity.

1999-04-09 Thread Andrea Arcangeli
(bh); bh-b_dev = B_FREE; insert_into_queues(bh); I just said exactly that some days ago in my _first_ email with the subject `buffer.c glitches'. Both invalidate_buffers() and set_blocksize() should put all invalidated buffers in the freelist. Andrea Arcangeli

Re: Race in buffer code (Was Re: move block #A to block #B on agiven device.)

1999-01-03 Thread Andrea Arcangeli
On Fri, 5 Nov 1999, Mikulas Patocka wrote: What if user does cat /dev/hda1/dev/null on mounted device while filesystem driver does getblk? ... the buffer gets corrupted. I was considering the case where the buffer returned by getblk is _just_ uptodate. If the block is just uptodate then all