From: Andreas Dilger <adilger@turbolabs.com>
To: Vijay Kumar <jkumar@qualcomm.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: kernel patch support large fat partitions
Date: Thu, 3 Jan 2002 17:24:36 -0700 [thread overview]
Message-ID: <20020103172436.I12868@lynx.no> (raw)
In-Reply-To: <5.1.0.14.0.20020103152205.039f2008@mage.qualcomm.com>
In-Reply-To: <5.1.0.14.0.20020103152205.039f2008@mage.qualcomm.com>; from jkumar@qualcomm.com on Thu, Jan 03, 2002 at 03:42:20PM -0800
On Jan 03, 2002 15:42 -0800, Vijay Kumar wrote:
> This limitation is imposed by the data structures used by the linux fat
> implementation to read/write directory entries. A 'long' data type is used
> to access directory entries on the disk, of which only 28 bits are used to
> identify the sector that contains the directory entry and the rest 4 bits
> are used to specify offset of the directory entry inside the sector. Using
> 28 bits to identify a sector means we cannot access sectors beyond 128GB
> (2^28*512), thus limiting us from creating partitions larger than 128GB on
> large disk drives.
Some minor notes on your patch:
1) It appears you are running an editor with 4-space tabs, and as a result
it has broken the indentation of some of your changes. This is easily
seen when looking at the patch.
2) It is almost certainly wrong to use "loff_t" for an inode number. Maybe
you could use "u64" instead? I also think that using "long long"
explicitly is frowned upon.
> I have made changes to fat, vfat and msdos file system implementations in
> the kernel to use larger data types, thus allowing us to create larger
> partitions. As per the GPL I would like to make the patch available to
> everyone and also in case somebody has run into the same problem(who cares
> about fat in the linux world). The patch has been fairly well tested only
> on our systems(p3, 700MHz with FC). I truly appreciate if you & anybody in
> the kernel mailing list have any feedback about the changes.
Does this change the on-disk format for FAT at all, or is it merely a
kernel filesystem code issue? I think only the latter, but best to check.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
next prev parent reply other threads:[~2002-01-04 0:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-03 23:42 kernel patch support large fat partitions Vijay Kumar
2002-01-04 0:24 ` Andreas Dilger [this message]
2002-01-04 0:34 ` Vijay Kumar
2002-01-04 2:48 ` CJ
2002-01-04 18:52 ` Vijay Kumar
2002-01-05 20:40 ` H. Peter Anvin
2002-01-05 0:12 ` Vijay Kumar
-- strict thread matches above, loose matches on Subject: below --
2002-01-04 10:40 Randal, Phil
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=20020103172436.I12868@lynx.no \
--to=adilger@turbolabs.com \
--cc=jkumar@qualcomm.com \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox