All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Mahoney <jeffm@suse.com>
To: ReiserFS Mailing List <reiserfs-devel@vger.kernel.org>
Subject: [PATCH] reiserfs: Remove 2 TB file size limit
Date: Tue, 30 Mar 2010 13:15:54 -0400	[thread overview]
Message-ID: <4BB231CA.2050109@suse.com> (raw)

 In its early life, reiserfs had an evolving s_max_bytes. It started out
 at 4 GB, then was raised to MAX_LFS_FILESIZE, then dropped to 2 TiB when
 it was observed that struct stat only had a 32-bit st_blocks field.

 Since then, both the kernel and glibc have evolved as well and now both
 support 64-bit st_blocks. Applications that can't deal with these ranges
 are assumed to be "legacy" or "broken." File systems now routinely
 support file sizes much larger than can be represented by 2^32 * 512.

 But we never revisited that limitation. ReiserFS has always been able to
 support larger file sizes (up to 16 TiB, in fact), but the s_max_bytes
 limitation has prevented that.

 This patch adds a max_file_offset helper to set s_max_bytes to a more
 appropriate value. I noticed that XFS adjusts the limit based on the
 CPU but I'd prefer to err on the side of compatibility and place the
 limit at the smaller of the 32-bit MAX_LFS_FILESIZE and the maximum
 supported by the file system. At a 4k block size, this is conveniently
 also the advertised maximum file size of reiserfs.

 This bug is tracked at: https://bugzilla.novell.com/show_bug.cgi?id=592100

Signed-off-by: Jeff Mahoney <jeffm@suse.com>
---
 fs/reiserfs/super.c |   17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

--- a/fs/reiserfs/super.c
+++ b/fs/reiserfs/super.c
@@ -1309,6 +1309,18 @@ out_err:
 	return err;
 }
 
+static inline loff_t
+reiserfs_max_file_offset(struct super_block *sb)
+{
+	/* Limited by stat_data->sd_blocks, 2^32-1 blocks */
+	loff_t fs_max = (sb->s_blocksize << 32) - sb->s_blocksize;
+
+	/* Limited by 32-bit MAX_LFS_FILESIZE */
+	loff_t page_cache_max = (((u64)PAGE_CACHE_SIZE << 31)-1);
+
+	return min(fs_max, page_cache_max);
+}
+
 static int read_super_block(struct super_block *s, int offset)
 {
 	struct buffer_head *bh;
@@ -1398,10 +1410,7 @@ static int read_super_block(struct super
 	s->dq_op = &reiserfs_quota_operations;
 #endif
 
-	/* new format is limited by the 32 bit wide i_blocks field, want to
-	 ** be one full block below that.
-	 */
-	s->s_maxbytes = (512LL << 32) - s->s_blocksize;
+	s->s_maxbytes = reiserfs_max_file_offset(s);
 	return 0;
 }
 

                 reply	other threads:[~2010-03-30 17:15 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=4BB231CA.2050109@suse.com \
    --to=jeffm@suse.com \
    --cc=reiserfs-devel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.