160GB drives by 2q2003?

A new type of portable drive is about to hit the market, called iVDR. They are talked about HERE.

Now, although these are Serial ATA, I would expect the technologies to be expanded to laptops!

So, anyone we know need 320GB?

The article mentions that one of the 3 expected prototypes would be a 2.5" with normal interface:

"Three prototypes are expected to be showcased there, including a 2.5-inch iVDR disk with a parallel ATA interface, and a 2.5 and 1.8-inch iVDR drive with a faster and less costly serial ATA interface"

And yeah, at least one member of this BBS would be expected to buy (at least) 2...

/Michael

You rang?

That is the only thing that (might) be holding me back from the new 80s when they come out - that this is just the beginning of a new wave of data storage density enhancements. Still, by the time it gets to market...

Still looking forward to the 80s, predicted 1Q03.

At the rate I'm accumulating bootlegs I might actually need to upgrade to 80s by then.

At the rate which I'm collecting music, I might add a second drive to my 30 by then. But more than likely, I'll just delete the crappy stuff that I just had for nostalgia's sake, which now just leaves me shaking my head wondering what the heck I was thinking. That'll free up more than I'd care to admit to.

Paul, give me a PM the second you know the 80's are available. I have a 60 and a 48 now, but have about 14GB sitting un-listened to now. The 60GB might be a bandaid for a bit, but a 80 would really be nice.

I heard that having a "monster drive" like these might require (or benefit from) a differant type of format or image.. is this true? Sometimes the Technical forum is a bit over my head - especially if I've been away for a month or so.

Greetings!

Not a problem. I will likely post giving exact details where to get them. If anyone else sees them for sale, please post as well. I just loaded some more audio books, and I am starting to run a bit close on space.

As for a different format or image, that is not really necessary. There were issues about space a while back, but it has been addressed. As long as you are running the most recent kernels (2.0b3 and I use the most recent hijack as well), you should be fine. You will need the updated disk builder code from the empeg site (dated 2001/10/22) in order to handle the larger drives, but it should not be an issue.

The scary part is the amount of time it takes to fsck the drives. Right now, the 60s run about 45 minutes - I hate to think what the 80s will be like... One hour per drive???

Meanwhile, when the 80s come out, if there are folks on the board who are interested in some used 60s... It will take a bit of time to cut everything over, but...

I'd be very interested in a pair of used 60's...

Greetings!

Send me an email message - I will hold onto it for when I decide to upgrade. The 80s still are not even out yet, and it will take time to copy the data even if I decide to immediately upgrade to the next largest drive...

The scary part is the amount of time it takes to fsck the drives. Right now, the 60s run about 45 minutes - I hate to think what the 80s will be like... One hour per drive???

Might be time to think about ext3. I haven't had any complaints about it in a while and with those big drives it will save you the fsck time.

-Mike

Hmm! I might give this a shot... Thanks for the link - I missed that before.

Me first!

ah... ext3 THAT's what I had heard of! Now.. ifwe can just make the database rebuilds faster.

Isn't the empeg subject to the 128GB limit per drive due to not supporting the newer 40-bit IDE/ATA addressing mode?

I thought Mark patched Hijack starting in version (mumble) to address it.

I thought Mark patched Hijack starting in version (mumble) to address it.

Yep, he did as of version 274 according to his page. Hopefully it still works with the ext3 changes.

-Mike

I thought Mark patched Hijack starting in version (mumble) to address it.

But the builder image that partitions the drives doesn't yet support the big disks. It'll have to be upgraded as well before big disk support happens.

Greetings!

I thought this had happened. When Mark was testing the changes to the hijack kernel for large drives, I thought he was testing with big desktop IDEs, upward of 120GB each on converters, and used the builder image to do the initial setup...

I might be wrong, but I thought the builder was tested at least that high.

You'd need to upload the Hijack kernel over the builder image still. The kernel in the builder image doesn't know how to do LBA48 addressing.

I'm assuming the actual application that does the formatting and partitioning of the drives supports drives that big. I've not tested it personally.

- Trevor

I'd recommend ext3 for really big drives; the bigger the drive, the more ram it needs to do a fsck. This is one of the issues with fscks being slow, it's because they're paging like hell during the fsck itself!

Hugo

I'd recommend ext3 for really big drives


When do you think that ext3-capable kernel and utilities might be included in a stock release? How many geek-months of testing would make you comfortable doing that?