FS limitation in empeg?

I understand that the current kernel is limited to a physical drive size of ~130GB. If I were to use two 120GB drives (available later this year), will I run out of inodes? Also, while I haven't had any file system problems that I know of, anybody (Mark?) thinking about implementing ext3?

Each file uses one inode. Unless you're creating boatloads of tiny files, it's not an issue. Drive size is of no relevance... you can run a small drive out of inodes too, but it's not likely to happen without trying very hard.

The issue of having large drives will be a problem if you try to use a single drive >128GB (or 137G in marketing speak). To get around that, you'd need a new IDE controller.

If I were to use two 120GB drives (available later this year), will I run out of inodes?

No. The number of inodes that are created when you put down the filesystem is relative to partition size. Larger partition -> more inodes.

If you know that you are going to use up a huge amount of inodes (creating loads of playlists, using the sym-link tree thing, filetaxiing gobs of small files etc etc) you might want to tweak the filesystem some (recreate it with a higher inode density). The builder .upgrade file uses a pretty low density of inodes since it is assumed that the filesize, on average, will be pretty large (say one 5MB tune file accompanied by a tags file of less than 1kB). Don't recall exactly what the density used is, but it's been posted on the board. Let's see, yup, here it is.

/Michael

Each file uses one inode.

I'm sorry, anyone what is an inode, but more relevant what is the inode max on the Empeg/Rio?

An inode is a pointer to a file in the filesystem. The amount of inodes is determined at filesystem creation time and can be varied due to what the filesystem is to be used for. If you're going to store only large files on the disk (let's say you DivX film archive - relatively few but large files) you'd want a low inode count, as each inode does take some overhead space. On the other hand, if you're going to use the disk for your news spool (lots and lots of small files), you want a high inode count, so that you don't run out of them. If you have no free inode you can't create a new file, no matter how much free space you have.

Per the link in my previous post, the inode density on the /dev/hdX4 partitions should be one inode per 128kB. Default for an ext2 is one per every 4 or 8kB, don't recall exactly which.

Edit: Calling it a pointer might be a bit simplified. It's a reserved space on disc which houses a list of pointers to blocks on the partition, as well as a pointer to one other such list of pointers (indirect) and a pointer to a list of pointers to lists (double indirection) and one triple indirection block. It is this structure, along with the size of a block, that sets the maximum file size possible, ie how many data block that can be pointed to by an inode. The inode also stores a number of dates (creation, last modified, etc), the rights set on the file, who owns the file, etc.

/Michael

Thanks Michael right now I seam to be having a brain melt down but I think I standunder I mean understand

Thanks for the info
JrFaust

Actually, the 128GB limitation can be overcome with a driver update.

If/when that becomes a real issue for the player, I'll code an update to my Linux IDE driver for it. Support is already being worked on in later 2.4/2.5 kernels.

-ml

The main issue I see with big drives, is the design of the player whereby it likes to put EVERYTHING (tunes, playlists, tag files) into one HUGE MASSIVE OVERSIZED LINEARLY INEFFICIENT directory.

Ext2 doesn't seem to cope well with this (linear filename lookups?), but at the time the player software was designed, drives were a heck of a lot smaller, so no fault there.

I might fix this someday in kernel space (by transparently multiplexing files into subdirectories, unbeknownst to the player software), as it could really speed up database rebuilds, syncs, and filesystem checks.

Especially on 128GB+ drives.

Cheers

Wouldn't it be easier to look into a journaling filesystem hack? After all, based on my last attempt of this, it should be possible by upgrading to a newer kernel to avoid the cross platform issues of ReiserFS.

I think the HUGE directory syndrome would still be a problem with ext3 (definitely) or reiserfs (supposedly better for large dirs, but much buggier IMHO).

-ml

<<No. The number of inodes that are created when you put down the filesystem is relative to partition size. Larger partition -> more inodes.>>

I wasn't sure how the file systems/partitions are created on the empeg. I had hoped that I wasn't working from the inode count of a 10GB drive.

BTW, the file system must take a beating. I always cycle the player off and pause a couple of seconds before pulling the empeg from it's sled, but I suspect others aren't so gentle. I remember when the ext2 file system would force an fsck every 10 or so IPLs but this isn't in place on the empeg? I can see ext3 operating reliably w. out having to force an fsck, but I worry about ext2 and all of my mp3 files. I

I've used my empeg for almost 2-years, and I'm not aware of any file system problems. I suspect ext2 and the empeg's method of shutting down must be pretty damn robust.

The drives are mounted read-only, which eliminates the possibility of corruption due to changes being buffered and not written out to disk. The only disk writing that is going on is to the scratch partition - and that is handled raw by the player.

The drives will be fscked when you've made 20 mounts read/write. Prior to the fun with Hijack etc that was pretty much limited to every 20th sync. This parameter can be tweaked, and Hijack has a setting to disable this default checking after 20 r/w mounts. If an operation occurs so that disk might be corrupted, it will still be fscked on next sync. If nothing has visibly gone wrong there is little point in forcing an fsck... just takes a &%¤& long time.

I suspect ext2 and the empeg's method of shutting down must be pretty damn robust.

It is mainly a function of keeping the disks read-only... yanking the player out while a write operations were underway isn't to be recommended

/Michael

reiserfs (supposedly better for large dirs, but much buggier IMHO)

It works for us (Rio Central uses it, as well as some future products).

There have been some conversations about switching the car player to ReiserFS, but one of the major issues is migration.

Rob

Actually, the 128GB limitation can be overcome with a driver update.

Ah, I'm glad to hear that from someone in a position to know what they're talking about. I suspected as much from the fact that Tivos, or was it ReplayTVs, can grok 128G drives with a software upgrade -- but it's easy to be persuaded otherwise by vendors of UDMA133 PCI cards for PCs...

Peter

HUGE MASSIVE OVERSIZED LINEARLY INEFFICIENT directory.

Yeah, we should have fixed that a long time ago, really. (And it's fairly trivial, just a few s|%08x|%05x/%03x| and emplode never needs to know.) But nothing in the player's normal function actually cares if directory lookup time is slow.

Peter

>Yeah, we should have fixed that a long time ago, really.
>(And it's fairly trivial, just a few s|%08x|%05x/%03x|
>and emplode never needs to know.) But nothing in the player's
>normal function actually cares if directory lookup time is slow.

Yup, I agree (with both parts). I could easily spoof this inside Hijack, and neither the player nor Emplode would ever know. But then the next beta kernel from SB would confuse things..

Actually, the 128GB units should work fine as-is. It's only the larger than 128GB drives that will have issues. And even those will work, truncated to 128GB.

Cheers

BTW, the file system must take a beating. I always cycle the player off and pause a couple of seconds before pulling the empeg from it's sled, but I suspect others aren't so gentle.

You do not need to do this. FAQ entry is here.

Yes, the nice thing about ext3 is that you can migrate ext2 without creating a new filesystem.

-Kit

ONE of the cool things... Fsck'ing on the fly is pretty cool too.