From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?J=F6rg?= Schummer Subject: Re: [PATCH take 2][RFC] fat: Save FAT root directory timestamps to volume label Date: Mon, 27 Jul 2009 17:56:03 +0300 Message-ID: <1248706563.4618.95.camel@jorg-desktop> References: <1248274841-3586-1-git-send-email-ext-jorg.2.schummer@nokia.com> <1248428635-26073-1-git-send-email-ext-jorg.2.schummer@nokia.com> <87fxclmhxy.fsf@devron.myhome.or.jp> <1248691635.4618.43.camel@jorg-desktop> <87ljmas5ym.fsf@devron.myhome.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" To: ext OGAWA Hirofumi Return-path: Received: from smtp.nokia.com ([192.100.122.230]:26150 "EHLO mgw-mx03.nokia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751363AbZG0O4Q (ORCPT ); Mon, 27 Jul 2009 10:56:16 -0400 In-Reply-To: <87ljmas5ym.fsf@devron.myhome.or.jp> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hello again, just in case you (or perhaps somebody else) have a minute to assist me.= =2E On Mon, 2009-07-27 at 13:47 +0200, ext OGAWA Hirofumi wrote: > BTW, the patch has several bugs. fat_get_label_entry() doesn't check > IS_FREE(), is it right? Not 100% sure if it's needed in a consistent fs, but I guess it shouldn't do any harm, so I added it. > fat_create_label_entry() doesn't initialize all > timestamp in the case of msdos. Corrected. > spin_lock() usage is wrong. >>From the code, I'm not totally sure then what inode_hash_lock is supposed to protect in fat_write_inode. Probably it should prevent that the dir entry of an inode is being moved around to another i_pos while it's being changed? But in the pre-patch version of fat_write_inode, shouldn't then mark_buffer_dirty(bh) be called when the lock is still held? Sorry for the newbie-questions, thanks for any help. J=C3=B6rg -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html