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 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.