So I wanted to vinum my new 1.9TB of disks together just for chuckles, and
it went OK up to the newfs..
S play.p0.s0State: up PO:0 B Size: 46 GB
S play.p0.s1State: up PO: 32 MB Size: 46 GB
S play.p0.s2State: up P
:S play.p0.s0State: up PO:0 B Size: 46 GB
:S play.p0.s1State: up PO: 32 MB Size: 46 GB
:S play.p0.s2State: up PO: 64 MB Size: 46 GB
:...
:S play.p0.s35 State: up PO: 1120 MB Size
> :S play.p0.s0State: up PO:0 B Size: 46 GB
> :S play.p0.s1State: up PO: 32 MB Size: 46 GB
> :S play.p0.s2State: up PO: 64 MB Size: 46 GB
> :...
> :S play.p0.s35 State: up PO: 112
Peter Wemm <[EMAIL PROTECTED]> wrote:
>
> /usr/include/sys/disklabel.h:
>u_int32_t p_size; /* number of sectors in partition */
>
> newfs.c:
> int fssize; /* file system size */
> ..
> havelabel:
> if (fssize == 0)
> fssize = pp->p_s
> > > The scary thing about this posting is that Joe was able to construct his
> > > 1TB+ filesystem with *ONLY* 37 hard drives.
> >
> > 37? 38. And you, a programmer! ;-) And that gets you 1.9TB (disk mfr
> > counting-wise). I'd have loved to break 2TB but couldn't imagine how to
>
On Tue, Feb 15, 2000 at 11:24:30AM -0800, John Milford wrote:
>
> Is there any real interest in moving beyond 1TB? I think that
> it would incur a non-trival overhead as I believe that unsigned ints
> would not work and we would be looking at going to 64 bit values. Or
> I guess something
:
:> > > The scary thing about this posting is that Joe was able to construct his
:> > > 1TB+ filesystem with *ONLY* 37 hard drives.
:> >
:> > 37? 38. And you, a programmer! ;-) And that gets you 1.9TB (disk mfr
:> > counting-wise). I'd have loved to break 2TB but couldn't imagine h
:Speaking of which, I'd like to compliment you on the overall design of the
:Diablo system. It has scaled very well to handle a hundred million articles
:on-spool.
:
:Dumping, hash table 67108864 entries, record size 28 <== :-) :-) :-)
:@268435472
:diload: 104146775/104146944 entries loaded
Matthew Dillon wrote:
> :>
> :> ie: there is a signed 32 bit sector count limit. 2^31 == 1TB. It shouldn
't
> :> be too hard to get it to create 2^32 bit (2TB) filesystem though. I'd exp
ect
> :> there to be more problems that this to bite you though. :-(
> :>
> :> 2^31 also happens to
> On Tuesday, 15 February 2000 at 3:40:58 -0600, Joe Greco wrote:
> > So I wanted to vinum my new 1.9TB of disks together just for chuckles, and
> > it went OK up to the newfs..
> >
> > S play.p0.s0State: up PO:0 B Size: 46 GB
> > S play.p0.s1State:
:
:> And, of course, the reader uses a multi-fork/multi-thread design,
:> resulting in an extremely optimal footprint.
:
:I hate your threads. Still trying to see some parts of the bigger
:picture. But it was a reasonable design decision, I'll grant.
heh heh. Be happy, it's second
On Tue, Feb 15, 2000 at 06:27:03PM -0800, John Milford wrote:
> Brooks Davis <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Feb 15, 2000 at 11:24:30AM -0800, John Milford wrote:
> > >
> > > Is there any real interest in moving beyond 1TB? I think that
> > > it would incur a non-trival overhead as I
On Tue, 15 Feb 2000, John Milford wrote:
> I will assert that it is insanity to build and use a 1TB UFS
> for small files (~ 2.5e8 inodes or 32GB) at least with the current
> technology. Maybe I am wrong, if anyone thinks so feel free to tell
It has to be said that whilst reading this thr
Greg Lehey wrote:
>
> On Tuesday, 15 February 2000 at 3:40:58 -0600, Joe Greco wrote:
> > So I wanted to vinum my new 1.9TB of disks together just for chuckles, and
> > it went OK up to the newfs..
> >
> > S play.p0.s0State: up PO:0 B Size: 46 GB
> > S play.p0.
Joe Greco wrote:
> So I wanted to vinum my new 1.9TB of disks together just for chuckles, and
> it went OK up to the newfs..
>
> S play.p0.s0State: up PO:0 B Size: 46 GB
> S play.p0.s1State: up PO: 32 MB Size: 46 GB
[..]
> S play.
> Joe Greco wrote:
> > So I wanted to vinum my new 1.9TB of disks together just for chuckles, and
> > it went OK up to the newfs..
> >
> > S play.p0.s0State: up PO:0 B Size: 46 GB
> > S play.p0.s1State: up PO: 32 MB Size: 46 GB
>
:> ie: there is a signed 32 bit sector count limit. 2^31 == 1TB. It shouldn't
:> be too hard to get it to create 2^32 bit (2TB) filesystem though. I'd expect
:> there to be more problems that this to bite you though. :-(
:>
:> 2^31 also happens to be the mmap() file offset limit FWIW.
2^3
> The trick to fsck is that you don't want more inodes than you really need.
> Once you get past that, fsck flies. The previous generation of binaries
> server, worked on 27 36GB drives split into 10 partitions, designed for
> parallelism. Hit RESET and the news filesystems take ~30 seconds to
> > The trick to fsck is that you don't want more inodes than you really need.
>
> > Once you get past that, fsck flies. The previous generation of binaries
> > server, worked on 27 36GB drives split into 10 partitions, designed for
> > parallelism. Hit RESET and the news filesystems take ~30 s
> > The scary thing about this posting is that Joe was able to construct his
> > 1TB+ filesystem with *ONLY* 37 hard drives.
>
> 37? 38. And you, a programmer! ;-) And that gets you 1.9TB (disk mfr
> counting-wise). I'd have loved to break 2TB but couldn't imagine how to
> handle th
:sure your amount of metadata that needs checking is reasonably low.
:
:> Also, it seems like 64 bit processors will be in use before 1 TB
:> filesystems are common. Won't the filesystem need to be 64-bitted for
:> that?
:
:I would guess. Matt Dillon commented on this already, though, and
:>
:> ie: there is a signed 32 bit sector count limit. 2^31 == 1TB. It shouldn't
:> be too hard to get it to create 2^32 bit (2TB) filesystem though. I'd expect
:> there to be more problems that this to bite you though. :-(
:>
:> 2^31 also happens to be the mmap() file offset limit FWIW.
N
> :Speaking of which, I'd like to compliment you on the overall design of the
> :Diablo system. It has scaled very well to handle a hundred million articles
> :on-spool.
> :
> :Dumping, hash table 67108864 entries, record size 28 <== :-) :-) :-)
> :@268435472
> :diload: 104146775/104146944 ent
On Tuesday, 15 February 2000 at 3:40:58 -0600, Joe Greco wrote:
> So I wanted to vinum my new 1.9TB of disks together just for chuckles, and
> it went OK up to the newfs..
>
> S play.p0.s0State: up PO:0 B Size: 46 GB
> S play.p0.s1State: up PO:
Brooks Davis <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 15, 2000 at 11:24:30AM -0800, John Milford wrote:
> >
> > Is there any real interest in moving beyond 1TB? I think that
> > it would incur a non-trival overhead as I believe that unsigned ints
> > would not work and we would be looking a
> Personally I think going to 64 bit block numbers is overkill. 32 bits
> is plenty (for the next few decades) and, generally, people running
> filesystems that large tend to be in the 'fewer larger files' category
> rather then the 'billions of tiny files' category, so using a l
> On Tue, Feb 15, 2000 at 06:27:03PM -0800, John Milford wrote:
> > Brooks Davis <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, Feb 15, 2000 at 11:24:30AM -0800, John Milford wrote:
> > > >
> > > > Is there any real interest in moving beyond 1TB? I think that
> > > > it would incur a non-
Joe Greco <[EMAIL PROTECTED]> wrote:
> >
> > Joe seem to want one. This size is certaintly within the reach of an
> > ISP now, and disks just keep getting bigger. My administrative bias is
> > that partitioning for a reason other then policy should be avoided and
> > thus I'd love to see files
On Tue, Feb 15, 2000 at 01:25:24PM -0800, Mike Smith wrote:
> > > The scary thing about this posting is that Joe was able to construct his
> > > 1TB+ filesystem with *ONLY* 37 hard drives.
...
> > I think you'll
> > continue to see a move towards some sort of "storage appliance" for vari
In the last episode (Feb 16), Greg Lehey said:
> On Tuesday, 15 February 2000 at 3:40:58 -0600, Joe Greco wrote:
>
> > Dunno how many terabyte filesystem folks are out there.
>
> None, by the looks of it.
Possibly no FreeBSD folks, but on Solaris, VXFS scales very well to
large volumes. We've
On Tue, 15 Feb 2000, Matthew Dillon wrote:
> Not with LVD. The whole point was to be able to have longer SCSI
> busses.
>
> LVD allows SCSI bus cable lengths up to 25 meters. With 16 devices
> the limit is 12 meters. That's 36 feet, folks!
Which isn't really that much, once y
On Tuesday, 15 February 2000 at 16:12:36 -0800, Matthew Dillon wrote:
>> sure your amount of metadata that needs checking is reasonably low.
>>
>>> Also, it seems like 64 bit processors will be in use before 1 TB
>>> filesystems are common. Won't the filesystem need to be 64-bitted for
>>> tha
:I think that at some point we'll need larger block numbers than will
:no longer fit in 32 bits. I'd rather we went to byte offsets, though,
:rather than block numbers.
:
:Greg
Good point. When we are faced with having to move from 32 to 64 bit
block numbers, I agree completely that we
On Wed, 16 Feb 2000, Dan Nelson wrote:
:In the last episode (Feb 16), Greg Lehey said:
:> On Tuesday, 15 February 2000 at 3:40:58 -0600, Joe Greco wrote:
:>
:> > Dunno how many terabyte filesystem folks are out there.
:>
:> None, by the looks of it.
:
:Possibly no FreeBSD folks, but on Solaris
On Tuesday, 15 February 2000 at 20:25:50 -0800, John Milford wrote:
> Joe Greco <[EMAIL PROTECTED]> wrote:
>
>>>
>>> Joe seem to want one. This size is certaintly within the reach of an
>>> ISP now, and disks just keep getting bigger. My administrative bias is
>>> that partitioning for a reason
35 matches
Mail list logo
