My turn to chime in.
JFS was designed around a 4K meta-data page size. It would require some
major re-design to use larger block sizes. On the other hand, JFS could
take advantage of 64-bit block addresses immediately. JFS internally
store the block address in 40 bits. (Sorry, file size & vol
On Mon, Mar 26, 2001 at 08:39:21AM -0800, LA Walsh wrote:
> So...is it the plan, or has it been though about -- 'abstracting'
> block numbes as a typedef 'block_nr', then at compile time
> having it be selectable as to whether or not this was to
> be a 32-bit or 64 bit quantity -- that way older s
Steve Lord wrote:
> Just a brief add to the discussion, besides which I have a vested interest
> in this!
I'll add my little comments as well, and hopefully not start a flamewar... :)
[snip comments about blocksize, etc.]
Here's a real-life example of something that most of you will probably ha
Hi,
Just a brief add to the discussion, besides which I have a vested interest
in this!
I do not believe that you can make the addressability of a device larger at
the expense of granularity of address space at the bottom end. Just because
ext2 has a single size for metadata does not mean every
Jan Harkes <[EMAIL PROTECTED]>:
>
> On Tue, Mar 27, 2001 at 01:57:42PM -0600, Jesse Pollard wrote:
> > > Using similar numbers as presented. If we are working our way through
> > > every single block in a Pentabyte filesystem, and the blocksize is 512
> > > bytes. Then the 1us in extra CPU cycles
Jan Harkes wrote:
>
> On Tue, Mar 27, 2001 at 01:57:42PM -0600, Jesse Pollard wrote:
> > > Using similar numbers as presented. If we are working our way through
> > > every single block in a Pentabyte filesystem, and the blocksize is 512
> > > bytes. Then the 1us in extra CPU cycles because of 64
On Tue, Mar 27, 2001 at 01:57:42PM -0600, Jesse Pollard wrote:
> > Using similar numbers as presented. If we are working our way through
> > every single block in a Pentabyte filesystem, and the blocksize is 512
> > bytes. Then the 1us in extra CPU cycles because of 64-bit operations
> > would add
- Received message begins Here -
>
> On Tue, Mar 27, 2001 at 09:15:08AM -0800, LA Walsh wrote:
> > Now lets look at the sites want to process terabytes of
> > data -- perhaps files systems up into the Pentabyte range. Often I
> > can see these being large multi-node (think
LA Walsh <[EMAIL PROTECTED]>:
> Ion Badulescu wrote:
> > Compile option or not, 64-bit arithmetic is unacceptable on IA32. The
> > introduction of LFS was bad enough, we don't need yet another proof that
> > IA32 sucks. Especially when there *are* better alternatives.
> ===
> So if it is a
On Tue, Mar 27, 2001 at 09:15:08AM -0800, LA Walsh wrote:
> Now lets look at the sites want to process terabytes of
> data -- perhaps files systems up into the Pentabyte range. Often I
> can see these being large multi-node (think 16-1024 clusters as
> are in use today for large super-clus
Ion Badulescu wrote:
> Are you being deliberately insulting, "L", or are you one of those users
> who bitch and scream for features they *need* at *any cost*, and who
> have never even opened up the book for Computer Architecture 101?
---
Sorry, I was borderline insulting. I'm getting pre
On Mon, 26 Mar 2001, Jonathan Morton wrote:
>>These are NOT the only 64 bit systems - Intel, PPC, IBM (in various guises).
>>If you need raw compute power, the Alpha is pretty good (we have over a
>>1000 in a Cray T3..).
>
>Best of all, the PowerPC and the POWER are binary-compatible to a very
>la
Manfred Spraul wrote:
> Which field do you access? bh->b_blocknr instead of bh->r_sector?
---
Yes.
>
> There were plans to split the buffer_head into 2 structures: buffer
> cache data and the block io data.
> b_blocknr is buffer cache only, no driver should access them.
---
My 'de
>These are NOT the only 64 bit systems - Intel, PPC, IBM (in various guises).
>If you need raw compute power, the Alpha is pretty good (we have over a
>1000 in a Cray T3..).
Best of all, the PowerPC and the POWER are binary-compatible to a very
large degree - just the latter has an extra set of 6
From: "LA Walsh" <[EMAIL PROTECTED]>
> Manfred Spraul wrote:
> >
> > >4k page size * 2GB = 8TB.
> >
> > Try it.
> > If your drive (array) is larger than 512byte*4G (4TB) linux will eat
> > your data.
> ---
> I have a block device that doesn't use 'sectors'. It
> only uses the logical block size (
Martin Dalecki <[EMAIL PROTECTED]>:
> "Eric W. Biederman" wrote:
> >
> > Matthew Wilcox <[EMAIL PROTECTED]> writes:
> >
> > > On Mon, Mar 26, 2001 at 10:47:13AM -0700, Andreas Dilger wrote:
> > > > What do you mean by problems 5 years down the road? The real issue is that
> > > > this 32-bit bl
On Mon, 26 Mar 2001, Andreas Dilger wrote:
> Matthew Wilcox writes:
> > people who can afford 2TB of disc can afford to buy a 64-bit processor.
> This whole "64-bit" fallacy has got to stop.
Indeed.
> Now it is "anybody who needs > 2TB disk should use a 64-bit CPU", soon
> to be wrong.
It was a
> "Matthew" == Matthew Wilcox <[EMAIL PROTECTED]> writes:
Matthew> On Mon, Mar 26, 2001 at 10:47:13AM -0700, Andreas Dilger
Matthew> wrote:
>> What do you mean by problems 5 years down the road? The real issue
>> is that this 32-bit block count limit affects composite devices
>> like MD RAID
"Eric W. Biederman" wrote:
>
> Matthew Wilcox <[EMAIL PROTECTED]> writes:
>
> > On Mon, Mar 26, 2001 at 10:47:13AM -0700, Andreas Dilger wrote:
> > > What do you mean by problems 5 years down the road? The real issue is that
> > > this 32-bit block count limit affects composite devices like MD
Manfred Spraul wrote:
>
> >4k page size * 2GB = 8TB.
>
> Try it.
> If your drive (array) is larger than 512byte*4G (4TB) linux will eat
> your data.
---
I have a block device that doesn't use 'sectors'. It
only uses the logical block size (which is currently set for
1K). Seems I could
On Mon, 26 Mar 2001, Matthew Wilcox wrote:
> people who can afford 2TB of disc can afford to buy a 64-bit processor.
You realise that this'll double the price of storage? ;)
(at least, in a year or two)
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly noth
- Received message begins Here -
>
> On Mon, Mar 26, 2001 at 08:39:21AM -0800, LA Walsh wrote:
> > I vaguely remember a discussion about this a few months back.
> > If I remember, the reasoning was it would unnecessarily slow
> > down smaller systems that would never have block
Matthew Wilcox <[EMAIL PROTECTED]> writes:
> On Mon, Mar 26, 2001 at 10:47:13AM -0700, Andreas Dilger wrote:
> > What do you mean by problems 5 years down the road? The real issue is that
> > this 32-bit block count limit affects composite devices like MD RAID and
> > LVM today, not just individ
On Mon, Mar 26, 2001 at 08:01:21PM +0200, Manfred Spraul wrote:
> drivers/block/ll_rw_blk.c, in submit_bh()
> >bh->b_rsector = bh->b_blocknr * (bh->b_size >> 9);
>
> But it shouldn't cause data corruptions:
> It was discussed a few months ago, and iirc LVM refuses to create too
> large volume
On Mon, Mar 26, 2001 at 10:47:13AM -0700, Andreas Dilger wrote:
> What do you mean by problems 5 years down the road? The real issue is that
> this 32-bit block count limit affects composite devices like MD RAID and
> LVM today, not just individual disks. There have been several postings
> I hav
>> I vaguely remember a discussion about this a few months back.
>> If I remember, the reasoning was it would unnecessarily slow
>> down smaller systems that would never have block devices in
>> the 4-28T range attached.
>
>4k page size * 2GB = 8TB.
Try it.
If your drive (array) is larger than 51
LA Walsh <[EMAIL PROTECTED]> writes:
> I vaguely remember a discussion about this a few months back.
> If I remember, the reasoning was it would unnecessarily slow
> down smaller systems that would never have block devices in
> the 4-28T range attached.
With classic 512 byte sectors the top si
Matthew Wilcox wrote:
>
> On Mon, Mar 26, 2001 at 08:39:21AM -0800, LA Walsh wrote:
> > I vaguely remember a discussion about this a few months back.
> > If I remember, the reasoning was it would unnecessarily slow
> > down smaller systems that would never have block devices in
> > the 4-28T ran
Matthew Wilcox writes:
> On Mon, Mar 26, 2001 at 08:39:21AM -0800, LA Walsh wrote:
> > I vaguely remember a discussion about this a few months back.
> > If I remember, the reasoning was it would unnecessarily slow
> > down smaller systems that would never have block devices in
> > the 4-28T range
On Mon, Mar 26, 2001 at 08:39:21AM -0800, LA Walsh wrote:
> I vaguely remember a discussion about this a few months back.
> If I remember, the reasoning was it would unnecessarily slow
> down smaller systems that would never have block devices in
> the 4-28T range attached.
4k page size * 2GB =
I vaguely remember a discussion about this a few months back.
If I remember, the reasoning was it would unnecessarily slow
down smaller systems that would never have block devices in
the 4-28T range attached.
However, isn't it possible there will continue to be a series
of P-IV,V,VI,VII ...etc,
31 matches
Mail list logo
