From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Moyer Subject: Re: Partition device synchronisation Date: Fri, 11 May 2012 09:39:26 -0400 Message-ID: References: <4FAC4208.1070308@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-fsdevel@vger.kernel.org To: "=?utf-8?Q?Vladimir_'=CF=86-coder=2Fphcoder'_Serbinenko?=" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:7920 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751693Ab2EKNj3 convert rfc822-to-8bit (ORCPT ); Fri, 11 May 2012 09:39:29 -0400 In-Reply-To: <4FAC4208.1070308@gmail.com> ("Vladimir =?utf-8?Q?'=CF=86-cod?= =?utf-8?Q?er=2Fphcoder'?= Serbinenko"'s message of "Fri, 11 May 2012 00:32:40 +0200") Sender: linux-fsdevel-owner@vger.kernel.org List-ID: "Vladimir '=CF=86-coder/phcoder' Serbinenko" writes= : > Hello, all. In GRUB we have tools to discover various parameters as t= o > how GRUB would see the disks on boot and for this we run the same cod= e > as we have in boot time in userspace. So most natural for us would be > accessing whole disks like sda but unfortunately its cache isn't kept > synchronous with partitions (e.g. sda1), so if FS driver writes > something to sda1 it won't be visible through sda until pages are > dropped. Right now in Linux-specific code we try to find which partit= ion > of sda starts at given sector (e.g. 2048) by trying all partition Lin= ux > sees in order to read from sda1 rather than sda. The code is ugly and > sometimes create issues. So my questions are: > 1) Do we have to issue some ioctl to reload those caches? You can issue the BLKFLSBUF ioctl. > 2) Is it considered a bug and should I plunge forward, fix it and sen= d a > patch? This is debatable. See this thread: http://thread.gmane.org/gmane.linux.kernel/1241227/focus=3D1244202 Cheers, Jeff -- 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