headers
Nick Piggin | 1 Nov 2008 09:04
Picon

Re: [patch 9/9] mm: do_sync_mapping_range integrity fix

On Fri, Oct 31, 2008 at 10:10:19AM -0400, Chris Mason wrote:
> On Fri, 2008-10-31 at 10:16 +0100, Nick Piggin wrote:
> > On Thu, Oct 30, 2008 at 04:13:44PM -0700, Andrew Morton wrote:
> > > On Wed, 29 Oct 2008 01:47:24 +1100
> > > npiggin <at> suse.de wrote:
> > > 
> > > > Chris Mason notices do_sync_mapping_range didn't actually ask for
> > data
> > > > integrity writeout. Unfortunately, it is advertised as being
> > usable for
> > > > data integrity operations.
> > > > 
> > > > This is a data interity bug.
> > > > 
> 
> [ use WB_SYNC_ALL instead of WB_SYNC_NONE ]
> 
> > >  If the caller
> > > is using sync_file_range() for integrity then the caller has done a
> > > SYNC_FILE_RANGE_WAIT_BEFORE.
> > 
> > No disputes about whether the API works "by design". But I think the
> > implementation has a bug. I'll explain:
> 
> I'll definitely agree the current usage is clumsy, and there is a bug in
> fs/buffer.c.  A grep through the rest of the filesystems doesn't turn up
> many assumptions that WB_SYNC_NONE means it's ok to skip dirty pages.
> 
> Greps for WB_SYNC_ALL and WB_SYNC_NONE in the fs code reveal:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vladislav Bolkhovitin | 1 Nov 2008 14:08

Re: FS corruption after I/O errors

Vladislav Bolkhovitin wrote:
> Nick Piggin wrote:
>> On Wednesday 29 October 2008 06:38, Vladislav Bolkhovitin wrote:
>>> Nick Piggin wrote:
>>>> On Saturday 25 October 2008 03:10, Vladislav Bolkhovitin wrote:
>>>>> Hi,
>>>>>
>>>>> During recent debugging session of my SCSI target SCST
>>>>> (http://scst.sf.net) I noticed many
>>>>>
>>>>> WARNING: at fs/buffer.c:1186 mark_buffer_dirty+0x51/0x66()
>>>>>
>>>>> messages in kernel log on the initiator. I attached the full log of
>>>>> several of them.
>>>>>
>>>>> My target was buggy and I was working on fixing it, but I suppose Linux
>>>>> should handle such failures more gracefully. In all the cases the target
>>>>> had one type of failure: it "ate" a SCSI command and never returned
>>>>> result of it.
>>>> Right. This is one of the warnings I see in my fault-injection testing.
>>>> It is fixed by my patch to clean up and improve the page and buffer
>>>> error handling in the vm/fs.
>>> Can you specify which patch you referring? Is it in 2.6.27?
>> It's just an RFC at the moment which I posted to fsdevel. Not in 2.6.27.
> 
> I see. I'm looking forward to see it in 2.6.28 or .29. This is really a 
> needed work.
> 
> BTW, have you even seen in your fault-injection testing that after 
> receiving a failure from a SCSI device during heavy load ext3 file
(Continue reading)

Permalink | Reply | 0 comments |
headers
Linus Torvalds | 1 Nov 2008 17:49
Gravatar

Re: [RFC][PATCH] saner FASYNC handling on file close


On Fri, 31 Oct 2008, Al Viro wrote:
>
> 	As it is, all instances of ->release() for files that have
> ->fasync() need to remember to evict file from fasync lists; forgetting
> that creates a hole and we actually have a bunch that *does* forget.
> 
> 	So let's keep our lives simple - let __fput() check FASYNC in
> file->f_flags and call ->fasync() there if it's been set.  And lose
> that crap in ->release() instances - leaving it there is still valid,
> but we don't have to bother anymore.
> 
> Comments?

This looks like "obviously the right thing". Done.

		Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Warren Turkal | 2 Nov 2008 02:11

looking for owner of HFS+

I am looking for the owner of the HFS+ module in Linux. I have a
couple small patches that I'd like to submit.

A quick git question also if anyone knows. If I forget to add
Signed-off by: lines to my commits, is there any way to go back to
those commits and add it short of recreating the series of commits in
another branch?

wt
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Brad Boyer | 2 Nov 2008 22:36

Re: looking for owner of HFS+

On Sat, Nov 01, 2008 at 06:11:59PM -0700, Warren Turkal wrote:
> I am looking for the owner of the HFS+ module in Linux. I have a
> couple small patches that I'd like to submit.

I would suggest starting with Roman Zippel. This is something I
used to do, but I haven't been an active maintainer since before
it even made it in to the official kernel. Roman was the one who
got it submitted, and is also the official maintainer of hfs
which now shares quite a bit of code with hfsplus.

	Brad Boyer
	flar <at> allandria.com

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Alexander Beregalov | 3 Nov 2008 14:33
Picon

Deadlock at io_schedule? (Re: linux-next: Tree for November 3)

Hi

2.6.28-rc3-next-20081103 on sparc64

SysRq : Emergency Sync
SysRq : Emergency Sync
SysRq : Emergency Sync
SysRq : Show Locks Held

Showing all locks held in the system:
1 lock held by pdflush/163:
 #0:  (&type->s_umount_key#13){----}, at: [<00000000004cf148>]
__sync_inodes+0x5c/0xd4
1 lock held by pdflush/164:
 #0:  (&type->s_umount_key#13){----}, at: [<00000000004cf148>]
__sync_inodes+0x5c/0xd4
1 lock held by metalog/1413:
 #0:  (&sb->s_type->i_mutex_key#3){--..}, at: [<0000000000488c88>]
generic_file_aio_write+0x44/0xc8
1 lock held by agetty/1630:
 #0:  (&tty->atomic_read_lock){--..}, at: [<00000000005ead9c>]
n_tty_read+0x20c/0x648
1 lock held by agetty/1632:
 #0:  (&tty->atomic_read_lock){--..}, at: [<00000000005ead9c>]
n_tty_read+0x20c/0x648
1 lock held by agetty/1634:
 #0:  (&tty->atomic_read_lock){--..}, at: [<00000000005ead9c>]
n_tty_read+0x20c/0x648
1 lock held by agetty/1636:
 #0:  (&tty->atomic_read_lock){--..}, at: [<00000000005ead9c>]
(Continue reading)

Permalink | Reply | 2 comments |
headers
Evgeniy Polyakov | 3 Nov 2008 15:11
Favicon
Gravatar

Re: [PATCH V2 10/16] Squashfs: cache operations

Hi.

Couple comments below.

On Wed, Oct 29, 2008 at 01:49:56AM +0000, Phillip Lougher (phillip <at> lougher.demon.co.uk) wrote:
> +struct squashfs_cache_entry *squashfs_cache_get(struct super_block *sb,
> +	struct squashfs_cache *cache, long long block, int length)
> +{
> +	int i, n;
> +	struct squashfs_cache_entry *entry;
> +
> +	spin_lock(&cache->lock);
> +
> +	while (1) {
> +		for (i = 0; i < cache->entries; i++)
> +			if (cache->entry[i].block == block)
> +				break;
> +
> +		if (i == cache->entries) {
> +			/*
> +			 * Block not in cache, if all cache entries are locked
> +			 * go to sleep waiting for one to become available.
> +			 */
> +			if (cache->unused == 0) {
> +				cache->waiting++;
> +				spin_unlock(&cache->lock);
> +				wait_event(cache->wait_queue, cache->unused);
> +				spin_lock(&cache->lock);
> +				cache->waiting--;
> +				continue;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Evgeniy Polyakov | 3 Nov 2008 15:11
Favicon
Gravatar

Re: [PATCH V2 11/16] Squashfs: block operations

Hi.

On Wed, Oct 29, 2008 at 01:49:56AM +0000, Phillip Lougher (phillip <at> lougher.demon.co.uk) wrote:
> +int squashfs_read_data(struct super_block *sb, void *buffer,
> +			long long index, int length, long long *next_index,
> +			int srclength)
> +{
> +	struct squashfs_sb_info *msblk = sb->s_fs_info;
> +	struct buffer_head **bh;
> +	int offset = index & ((1 << msblk->devblksize_log2) - 1);
> +	long long cur_index = index >> msblk->devblksize_log2;
> +	int avail, bytes, compressed, b = 0, k = 0;
> +	int c_byte = length;
> +
> +	bh = kcalloc((msblk->block_size >> msblk->devblksize_log2) + 1,
> +				sizeof(*bh), GFP_KERNEL);

Could be great to have a memory pool though...

--

-- 
	Evgeniy Polyakov
Permalink | Reply | 0 comments |
headers
Evgeniy Polyakov | 3 Nov 2008 15:14
Favicon
Gravatar

Re: [PATCH V2 00/16] Squashfs: compressed read-only filesystem

Hi.

On Wed, Oct 29, 2008 at 01:49:55AM +0000, Phillip Lougher (phillip <at> lougher.demon.co.uk) wrote:
> Summary of changes in patch respin:
> 
> 1. Functions changed to return 0 on success and -ESOMETHING on error
> 2. Header files moved from include/linux to fs/squashfs
> 3. Variables changed to use sb and inode
> 4. Number of squashfs_read_metadata() parameters reduced
> 5. Xattr placeholder code tweaked
> 6. TRACE and ERROR macros fixed to use pr_debug and pr_warning
> 7. Some obsolete macros in squashfs_fs.h removed
> 8. A number of gotos to return statements replaced with direct returns
> 9. Sparse with endian checking (make C=2 CHECKFLAGS="-D__CHECK_ENDIAN__")
>    errors fixed
> 10. get_dir_index_using_name() misaligned access fixed
> 11. Fix a couple of printk warnings on PPC64
> 12. Shorten a number of variable names

Looks very good.

As a generic comment of the style: imho u64 is more appropriate than
long long, at least it is less keys to press when typing :)

--

-- 
	Evgeniy Polyakov
Permalink | Reply | 0 comments |
headers
Andrew Morton | 3 Nov 2008 21:27

Re: [PATCH] improve jbd fsync batching

On Tue, 28 Oct 2008 16:16:15 -0400
Josef Bacik <jbacik <at> redhat.com> wrote:

> Hello,
> 
> This is a rework of the patch I did a few months ago, taking into account some
> comments from Andrew and using the new schedule_hrtimeout function (thanks
> Arjan!).
> 
> There is a flaw with the way jbd handles fsync batching.  If we fsync() a file
> and we were not the last person to run fsync() on this fs then we automatically
> sleep for 1 jiffie in order to wait for new writers to join into the transaction
> before forcing the commit.  The problem with this is that with really fast
> storage (ie a Clariion) the time it takes to commit a transaction to disk is way
> faster than 1 jiffie in most cases, so sleeping means waiting longer with
> nothing to do than if we just committed the transaction and kept going.  Ric
> Wheeler noticed this when using fs_mark with more than 1 thread, the throughput
> would plummet as he added more threads.
> 
> ...
>
> ...
>  
>  <at>  <at>  -49,6 +50,7  <at>  <at>  get_transaction(journal_t *journal, transaction_t *transaction)
>  {
>  	transaction->t_journal = journal;
>  	transaction->t_state = T_RUNNING;
> +	transaction->t_start_time = ktime_get();
>  	transaction->t_tid = journal->j_transaction_sequence++;
>  	transaction->t_expires = jiffies + journal->j_commit_interval;
(Continue reading)

Permalink | Reply | 2 comments |

Gmane