..
Yeah.  Except Dell will undoubtedly have them in desktops

within 2 years, and tons of people (myself included) still use

32-bit (K)Ubuntu on our systems, simply for the better binary

compatibility that it is perceived to give with things like

browser plugins and stuff.
Using sysfs interfaces might be a good alternative,

if they were easier to use, but drives are not directly

accessible there using the dev_t value from stat(2).
Instead, software has to search everything inside /sys/block/

looking for a "dev" file whose contents match,

rather than just trying to access something like this:
   /sys/block/8:1/start

or

   /sys/block/majors/8/minors/1/start
Or any one of a number of similar ways to arrange it.
Cheers

--

I think that there are many embedded applications (lots of them linux based)

which have large amounts of storage behind low power, low cost 32 bit CPU's.
Think of the home/small office NAS boxes that you can get from bestbuy or other

big box stores. Those devices today have 4 S-ATA drives (each of which can be

1TB in size).
Also, if you have a very low end box, it can still access really large storage

over iSCSI or a SAN which will present as a local, large device.
Over time, even these low end CPU's will migrate towards 64 bits, but we are not

there yet...
ric
--

Don't those devices run into trouble with fsck?  The amount of memory

you need to fsck a device is obviously going to depend on the filesystem,

but it has to grow with device size, and I'm not sure that 4GB is enough

virtual address space to fsck 2TB.
--

Intel are signing my paycheques ... these opinions are still mine

"Bill, look, we understand that you're interested in selling us this

operating system, but compare it to ours.  We can't possibly take such

a retrograde step."

--

Absolutely - they more or less hit a stonewall once the disk has any trouble and

you need to fsck.  On the other hand, this might be merciful since on 64 bit

boxes, we will let you run the fsck and watch it run for a week or so before you

despair ;-)
On a serious note, fsck time tends to track more the number of active inodes, so

you can fsck a large file system if you use it to store large files (especially

if you use a file system with dynamic inode creation or something like the

uninitialized ext4 inodes).
ric
--

Well 2TB, assuming a 4k blocksize, means a block bitmap is 512 megs.

So at least for ext3, 4GB should be just enough, unless you hit

certainly really nasty complicated corruptions (i.e. large number of

blocks claimed by more than one inode, which can happen if an inode

table is written to the wrong location on disk --- on top of some

other portion of the inode table), or if the filesystem has a large

number of files with hard links (such as the case with certain backup

programs).
The plan is to implement some kind of run-length encoding to compress

the in-memory requirements for storing the bitmaps, but that hasn't

been coded yet.  If someone is a staff programmer for one of these

bookshelf NAS manufacturers is interested in implementing such a

beast, they should talk to me; I've thought quite a bit about the
And ext4 extents will help because it reduces the number of indirect

blocks you have to read, which will significantly reduce the fsck

time.  So there will be improvements on the horizon.
       	  	     		     	- Ted
--

Whoops, screwed up my math.  The block bitmap for a 2TB filesystem is

64 megs, not 512 megs.  2*41 / 2**12 / 2**3 == 2**26, or 64mb.  E2fsck

in the worst case will allocate 5 inode bitmaps and 3 block bitmaps,

plus various arrays for directory blocks and keeping track of

refcounts (which are optimized for counnts of 0 and 1, so lots of hard

links will blow up your memory usage, although we do have a tdb option

which helps in that particular case).  So I'd say that most of the

time 3GB of address space should really be enough for a 2TB raid

array, unless you get really pathalogical corruption cases.
							- Ted

--

I can attest to this. I hear from a reliable source (manufacturer)

that 2TB 3.5" disks will be out no later than first half of 2009

(possibly even sooner, or at least 1.5TB). I currently use 1TB disks

with a Geode LX based motherboard for SATA RAID and I plan on

upgrading/consolidating to larger sizes once they become available in

the market. 64-bit is not an option for me on this hardware.
-Andrew

--

We provide data services to our clients.  We are already seeing USB

enclosures routinely provided to us by our clients with 1TB.  1.5TB on

occasion.  2TB usb enclosures can't be far behind.
For usb a bigger factor than anything is when will MS offer

compatibility/supportfor 2TB+ drives.  As soon as they become readily

supported in MS, our clients will start buying them and filling them

up and we will need to be able to access them from all of our systems.

(old and new).
Greg

--

Greg Freemyer

Litigation Triage Solutions Specialist

http://www.linkedin.com/in/gregfreemyer

First 99 Days Litigation White Paper -

http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf
The Norcross Group

The Intersection of Evidence & Technology

http://www.norcrossgroup.com

--