linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Kleikamp <shaggy@austin.ibm.com>
To: tonyb@cybernetics.com
Cc: fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] [RFC] LBD fixes for Linux 2.6.10 [1/2]
Date: Thu, 13 Jan 2005 13:45:48 -0600	[thread overview]
Message-ID: <1105645548.7747.6.camel@localhost> (raw)
In-Reply-To: <05Jan11.134758est.332232@cyborg.cybernetics.com>

On Tue, 2005-01-11 at 13:47 -0500, Tony Battersby wrote:
> This patch fixes some LBD problems in the core Linux filesystem code.
> I will send another message that has fixes for various filesystems.
> 
> (For review, enabling LBD [large block device support] changes sector_t
> to a 64-bit quantity on i386 to support disks >= 2 TB.  All sector
> numbers should be of type sector_t rather than long or unsigned long,
> which are only 32-bit on i386.  One must also be careful to typecast
> long or int values to a 64-bit value before shifting left to avoid
> losing bits.)
> 
> I haven't tested these changes at all, so please review and comment.
> 
> Anthony J. Battersby
> Cybernetics

This patch should fix up jfs.  It's probably not really necessary, since
jfs only support a 4K block size, and we're still limited by a 32-bit
page->index.  However, jfs uses long longs in most of the code, so it
doesn't hurt to fix the few places where we're inconsistent.

It compiles cleanly.  That's the extent that it's tested.

diff -urp linux-2.6.11-rc1/fs/jfs/jfs_metapage.c linux/fs/jfs/jfs_metapage.c
--- linux-2.6.11-rc1/fs/jfs/jfs_metapage.c	2005-01-13 13:14:42.242336808 -0600
+++ linux/fs/jfs/jfs_metapage.c	2005-01-13 13:31:26.039736408 -0600
@@ -162,7 +162,7 @@ void metapage_exit(void)
  * Basically same hash as in pagemap.h, but using our hash table
  */
 static struct metapage **meta_hash(struct address_space *mapping,
-				   unsigned long index)
+				   sector_t index)
 {
 #define i (((unsigned long)mapping)/ \
 	   (sizeof(struct inode) & ~(sizeof(struct inode) -1 )))
@@ -174,7 +174,7 @@ static struct metapage **meta_hash(struc
 
 static struct metapage *search_hash(struct metapage ** hash_ptr,
 				    struct address_space *mapping,
-			       unsigned long index)
+				    sector_t index)
 {
 	struct metapage *ptr;
 
@@ -209,7 +209,7 @@ static void remove_from_hash(struct meta
 		mp->hash_next->hash_prev = mp->hash_prev;
 }
 
-struct metapage *__get_metapage(struct inode *inode, unsigned long lblock,
+struct metapage *__get_metapage(struct inode *inode, sector_t lblock,
 				unsigned int size, int absolute,
 				unsigned long new)
 {
@@ -218,10 +218,11 @@ struct metapage *__get_metapage(struct i
 	int l2bsize;
 	struct address_space *mapping;
 	struct metapage *mp;
-	unsigned long page_index;
+	sector_t page_index;
 	unsigned long page_offset;
 
-	jfs_info("__get_metapage: inode = 0x%p, lblock = 0x%lx", inode, lblock);
+	jfs_info("__get_metapage: inode = 0x%p, lblock = 0x%llx", inode,
+		 (unsigned long long)lblock);
 
 	if (absolute)
 		mapping = inode->i_sb->s_bdev->bd_inode->i_mapping;
@@ -390,7 +391,7 @@ static void __write_metapage(struct meta
 {
 	int l2bsize = mp->mapping->host->i_blkbits;
 	int l2BlocksPerPage = PAGE_CACHE_SHIFT - l2bsize;
-	unsigned long page_index;
+	sector_t page_index;
 	unsigned long page_offset;
 	int rc;
 
@@ -513,7 +514,7 @@ void release_metapage(struct metapage * 
 void __invalidate_metapages(struct inode *ip, s64 addr, int len)
 {
 	struct metapage **hash_ptr;
-	unsigned long lblock;
+	sector_t lblock;
 	int l2BlocksPerPage = PAGE_CACHE_SHIFT - ip->i_blkbits;
 	/* All callers are interested in block device's mapping */
 	struct address_space *mapping = ip->i_sb->s_bdev->bd_inode->i_mapping;
diff -urp linux-2.6.11-rc1/fs/jfs/jfs_metapage.h linux/fs/jfs/jfs_metapage.h
--- linux-2.6.11-rc1/fs/jfs/jfs_metapage.h	2005-01-13 13:14:42.243336656 -0600
+++ linux/fs/jfs/jfs_metapage.h	2005-01-13 13:19:45.826185048 -0600
@@ -43,7 +43,7 @@ struct metapage {
 	 * add the metapage to the hash before we have the real page
 	 */
 	struct address_space *mapping;
-	unsigned long index;
+	sector_t index;
 	wait_queue_head_t wait;
 
 	/* implementation */
@@ -70,7 +70,7 @@ struct metapage {
 
 /* function prototypes */
 extern struct metapage *__get_metapage(struct inode *inode,
-				  unsigned long lblock, unsigned int size,
+				  sector_t lblock, unsigned int size,
 				  int absolute, unsigned long new);
 
 #define read_metapage(inode, lblock, size, absolute)\

-- 
David Kleikamp
IBM Linux Technology Center


      reply	other threads:[~2005-01-13 19:45 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-11 18:47 [PATCH] [RFC] LBD fixes for Linux 2.6.10 [1/2] Tony Battersby
2005-01-13 19:45 ` Dave Kleikamp [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1105645548.7747.6.camel@localhost \
    --to=shaggy@austin.ibm.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tonyb@cybernetics.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).