I tried the patch, same problem show up, but no bug_on report Is there any other things I can do? -

Do u mean 2T here?, but in both configuartion, the component devices are I386(i686) Gcc 4.0.2 20051125, OK, I will try the patach and post the result. Best Regards Jeff Zheng -

Most CIFS servers (Windows on NTFS, Samba etc.) can return a "unique identifier" (a 64 bit inode number), in conjunction with the volume id, that is probably good enough ... right? This can be returned on various calls (level 0x03EE "file_internal_info" - returns only this number). If reverse lookup is required - ie given a "unique identifier" what is its path name - there are probably a few different ways to handle this but presumably local filesystems run into the same issue. Steve Fr...

While others are busy coming up with new silly names, here is something substantial to worry about. Patches fixes a deadlock problem well enough for LogFS to survive. The problem itself is generic and seems to be ancient. Shaggy has code in JFS from about 2.4.20 that seems to work around the deadlock. Dave Chinner indicated that this could cause latency problems (not a deadlock) on the NFS server side. I still suspect that NTFS has hit the same deadlock and its current "fix" will cause data cor...

I don't remember enjoying the experience too much. For a day or two I through. Not sure how the monasteries would cope with that. J=C3=B6rn --=20 I've never met a human being who would want to read 17,000 pages of documentation, and if there was, I'd kill him to get him out of the gene pool. -- Joseph Costello -

I would strongly suggest you used (0, PAGE_CACHE_SIZE) for the range, and have your nopage function DTRT. Minor issue: you can just check for `if (!page->mapping)` for truncation, which is the usual signal to tell the reader you're checking for truncate. Rather than add this (not always correct) comment about the VM workings, I'd just add a directive in the page_mkwrite API documentation that the filesystem -- SUSE Labs, Novell Inc. -

You don't know how much you're going to change, but it could be anything in the range of 0 to PAGE_CACHE_SIZE. Clearly a (0, PAGE_CACHE_SIZE) Oh god you're doing ClearPageUptodate directly on pagecache pages? In general (modulo bugs and crazy filesystems), you're not allowed to have !uptodate pages mapped into user addresses because that implies the user would be allowed to see garbage. If you follow that rule, then you can never have a !uptodate page be passed into page_mkwrite (unless it ha...

Which ways? Are you talking about prepare_write being called from page_mkwrite, or anywhere? More generally it sounds like a nasty thing to have a writeback cache if it can become incoherent (due to dirty pages that subsequently cannot be written back) without notification. Have you tried doing a write-through one? You may be clearing PG_uptodate, but isn't there still an underlying problem that you can have mappings to the page at that point? If that isn't a problem truncate_complete_page ...

It had better not. We use that sucker to nuke pagecache when we're trying to You can drop the lock, do the invalidation, and return AOP_TRUNCATED_PAGE. The I just mean more generally. simple write(2) writes, for starters. For shared writable mmap? I don't know... does POSIX require mmap data That's what the invalidate / truncate routines do. -- SUSE Labs, Novell Inc. -

You can't do write-through caching for shared-writable mmap because the writes go directly into the pagecache once the page is made writable, at least, short of instruction emulation. At some point in the future we'll be asked to turf the data back to the I suspect so, but I don't know offhand. I want it to be coherent anyway, otherwise it's inconsistent with OpenAFS and Arla (or at least more so). Note also that the choice of write-through or write-back caching also has implications for loc...

Looks like cifs has grown and export_operations table since I did the patch. But with only a get_parent method that returns and error it's not useful at all, so we should rather remove the whole file: Signed-off-by: Christoph Hellwig <hch@lst.de> Index: linux-2.6/fs/cifs/cifsfs.c =================================================================== --- linux-2.6.orig/fs/cifs/cifsfs.c 2007-05-16 07:55:35.000000000 +0200 +++ linux-2.6/fs/cifs/cifsfs.c 2007-05-16 07:55:50.000000000 +0200 @...

What cases are you thinking of? --b. -

Hm. How could nfsd get stale metadata? I'm just (probably naively) assuming that a "cluster" filesystem attempts to provide much higher cache consistency than actually necessary to keep nfs clients happy. But, if not, it would be nice to understand the problem. --b. -

If I read this correctly, the problem is with JFS rather than RAID? Have you tried not mounting the JFS filesystem but just starting the array which crashes, so you can read bits of it, etc, and verify that the array itself is working? And can you run an fsck on the filesystem, if that makes sense? I assume you got to actually write a f/s at one time, and I've never used JFS under Linux. I spent five+ years using it on AIX, though, complex but -- bill davidsen <davidsen@tmr.com> ...

Check if your kernel has CONFIG_LBD enabled. The kernel doesn't check if the block layer can actually write to a block device > 2TB. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. -

You will definitely meet the same problem. As very large hardware disk becomes more and more popular, this will become a big issue for software raid. Jeff -----Original Message----- From: david@lang.hm [mailto:david@lang.hm] Sent: Thursday, 17 May 2007 6:04 a.m. To: Andreas Dilger Cc: Jeff Zheng; linux-kernel@vger.kernel.org; linux-fsdevel@vger.kernel.org Subject: Re: Software raid0 will crash the file-system, when each disk is 5TB my experiance is taht if you don't have CONFIG_LB...

Problem is that is only happens when you actually write data to the raid. You need the actual space to reproduce the problem. Jeff -----Original Message----- From: Jan Engelhardt [mailto:jengelh@linux01.gwdg.de] Sent: Thursday, 17 May 2007 6:17 a.m. To: david@lang.hm Cc: Andreas Dilger; Jeff Zheng; linux-kernel@vger.kernel.org; linux-fsdevel@vger.kernel.org Subject: Re: Software raid0 will crash the file-system, when each disk is 5TB few more days. You could emulate it with VMware. B...

That's assuming blocks were actually allocated - if the prealloc range already has underlying blocks there is no change and so we should not be changing mtime either. Only the filesystem will know if it has changed the file, so I think that timestamp updates need to be driven down to that level, not done blindy at the highest layer.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group

I think ->fallocate() should return a "long", since sys_fallocate() has to return what ->fallocate() returns and hence their return type should I will change the ext4_fallocate() to return a "long" (in patch 4/5) in the next post. Agree ? Thanks! -- Regards,

Dave asked me about that the other day (in relation to the ->fault ops)... I have no problem merging it for 2.6.22 and rebasing my patches on top. -- SUSE Labs, Novell Inc. -

I say I believe scalability will not be a huge issue, because for concurrent faulters on the same page, they still have cacheline contention beginning before we lock the page (tree_lock), and ending after we unlock it (page->_count), and a few others in the middle for good mesure. I sure don't think it is going to help, but I don't think it would be a great impact on an alrady sucky workload. We would have contention against other sources of lock_page, but OTOH, we want to fix up the clear_...

Or did you mean one fewer negative? :-) David -

Derrr... I'm an idiot! -- -

I know. Top 3 items of my todo list are: - Handle system crashes - Add second journal That will get resurrected, even before the move to userspace. I had to change the filesystem format for compression support and this is an artifact of the transition phase. J=C3=B6rn --=20 Ninety percent of everything is crap. -- Sturgeon's Law -

Hmm. I am not sure how this could be generic and still make sense. LogFS has some unused write-once space in the superblock segment. Embedded people always have problems debugging and were suggesting usin= g this to store debug information. That allows me to ask for a filesyste= m image and get both the offending image plus a crash dump. It also allows me to abort mounting if I ever see an existing crash dump (not implemented yet). "First failure data capture" was an old IBM slogal and the ...