That would be similar to trying to unsubscribe from a spam list.

The .patch file is MASSIVE

Why don't you bzip2 it? That takes 89% off.

Pim

Funny,
I just had to verify that hijack really shows up on googles first page.
And what happens ?
Five minutes later I get an (automated) email from security about:
"Reconsidering if researching certain terms [hijack] on the web can really be justified by business needs."
(The mail was _much_ longer...)

I guess they're just a little paranoid.
And I should bypass that proxy.

On a second thought, I wonder if they will log this message, since it contains the word [hijack]....


Oh yes.
@hijack: Happy Birthday !
@Mark: keep up the good work!

In reply to:

---

are the e2fsutils backwards compatible? so i don't have to worry if my partitions are ext2 still.

---

Yes. I still run my root and programs partitions as ext2 with no problems.

-Mike

Hey Mike, I upgraded my music and /usr partitions to ext3 no problem. I was thinking about doing the same with my root partition but I got this nagging feeling that it might be a bad idea. Any reason not to convert the root partition too? I know that future .upgrades will be laying down an ext2 filesystem, so they'd have to be converted after each upgrade. I don't mind doing that... Is there any other reason that upgrading the root partition to ext3 is a bad idea?

In reply to:

---

Is there any other reason that upgrading the root partition to ext3 is a bad idea?

---

Good question. I haven't tried it myself, but I don't think it will work. The root partition is mounted directly by the kernel IIRC and it does not seem to use the normal mount call that I tweaked to get the other partitions to magically mount as ext3. I think you would have to hack up the kernel a bit more to find where and how it mounts / and change that call. I didn't bother since that partition is small enough that an fsck doesn't take any real time. Also, since the root partition is so small I wouldn't want to waste the space that would be taken up by the journal file. Anyway, YMMV but I wouldn't recommend it.

-Mike

Okay, that makes sense. Does a journal file really take up that much space, BTW?

The only reason I wanted to try is that my root partition and my /usr partition seem to be the ones I always screw up and forget to mount read-only.

In reply to:

---

Does a journal file really take up that much space, BTW?

---

The amount of space used is relative to the size of the partition, but I don't know if there is a minimum amount that is always used. As a reference tune2fs created a 30Meg journal file for my 30Gig drive in my main empeg.

-Mike

<slightly tardy>
mirror at Empeg-Hijack.com updated for anyone who has trouble getting to sourceforge.
</slightly tardy>

In reply to:

---

Stupid bloody buggers. They could be searching somebody else, instead of wasting their time on me four times a week.

---

But look it from their [computer systems] point of view:

You are a known "Hijacker", you associate with "hijackers" and you're a foreigner [Canadian] who travels a lot in USA.

Therefore according to their "profile assessments" of what average "hijacker" looks like - you must rate right up there with Osama and his mates in terms of security risk!

Naw, I figure they're just hassling me cuz I'm "taking jobs 'way from 'mericans!", or somethin' like that.

Cheers

It's when I try to actually board the plane that I get pulled aside, 100% of the time. Actually, it really happens at check-in -- my boarding card gets flagged with some kind of special marking indicating that I must be hand-checked.

Ahh, ok. I got randomly selected flying out of COS, but never on the way home. My friend who flew recently got randomly picked for this search at the gate as well. Thats really odd that you have been nailed every single time.

I have upgraded to Hijack v.3.00 and It say here that
"the journaling file system stuff is included with this version",
but "not turned on by default"

How do I "turn it on"?
I followed the link to http://macgeek.dyndns.org/empeg/ext3/
and it reads "All the patches below have been integrated into hijack"

So I am assuming that there is nothing to apply to the player,
I just don't seem to be able to figure out how to actually see the benefit.
Is it automatically setup up for me by applying Hikack v3.00
or do I have to issue a bunch of commands to the player to actually implement this type of filesystem?
If so, what, specifically are those commands?

Did I miss a FAQ entry or do I smell a new one coming?

Also, what, if any are the benefits?
I know that fsking is cut out, but are there any other performance advantages?
Does this have anything to do with beta 13's new way of organizing FID's ?

P.S. Sorry for all the questions but I am a linux newbie, so please, use kid gloves, thanks

If you're a newbie to Linux, I recommend that you do nothing with the new ext3 features in the kernel. There will not be any immediate benefit to you.

The biggest benefit is "no disk checks", but that is already there in Hijack because it has a menu option "Filesystem check on sync=Disabled" that you can use.

As a software developer, there might be some benefits to using ext3 on the player, but if you're just a regular user then you shouldn't convert your file system.

At the moment I agree with Tony. But ext3 might have benefits for non-developers in the future. If we ever develop any applications that want to write to disk whilst in the car, then ext3 has major benefits over ext2.

I smell something brewing

I don't think you quite follow that there's a good amount of difference between the don't check option and what ext3 provides. Even if you do, it's worth pointing out in more detail.

The normal filesystem, ext2, keeps a log of how many times it's been mounted. Once it reaches a certain number, it ``requests'' that it be checked on the assumption that it might have become corrupted without it noticing. For many applications, the empeg included, this is useless. The don't check option turns this off, so you won't get the occasional slow empeg start.

Ext3, on the other hand, is a journalling filesystem. This means that every time a change is made to the filesystem, a log is written that says the filesystem is about to be modified, then the change is made, then the log is erased. (I'm sure that this is not totally accurate, but it's generally the idea.) The benefit of this is that if the filesystem is forcibly unmounted, as from the power being removed, the filesystem driver can see if there are any logs that weren't erased. If there were, then it can find the partial change and back it out. (Again, probably not quite accurate.) This means that filesystem checks needn't be performed at all. Mostly. Of course, in order for changes to occur, the filesystem must be mounted read-write, and the filesystem driver for both filesystems understands this, so it's never checked due to a forcible unmount of a read-only filesystem.

Since, for non-hackers, the empeg's filesystems are only mounted read-write when syncs are being performed, this occurs fairly seldom -- only when the power is removed during a sync, or crashes. But they can happen.

But you're right that it's much more likely to help a hacker-type. But, IMHO, what would be more likely to help is just to remember to unmount the filesystems cleanly.

Tony, I think you are seriously understating the deal with ext3.

The reason there are no file system checks isn't as simple as the case for hijack, where they're just turned off.

There actually are file system checks with ext3, they just happen a lot faster because
it's a journaling file system and it's much harder to get it into a state where there is real
corruption. It's a much more robust solution.

I realize you probably know this stuff, but I don't know if everyone does.

Anyway, if indeed everything you need is built into the latest hijack (I haven't checked
myself), you just need to:

1) run tune2fs -j on the partitions
2) make sure they are mounted as ext3 -- it's been awhile since I poked around on the player, so I can't remember if there is an fstab to tweak in this regard.

As someone else stated, it may be tricky to get the root partition mounted ext3, I am not really sure.

I should think Mark would chime in, being the file system stud he is :-)

Cheers,
rjf&

In reply to:

---

How do I "turn it on"?

---

As has been pointed out by a few other people, if you aren't comfortable with this and don't know what ext3 is you probably don't want to try this just yet. If you are feeling brave (or foolish) what you need to do is go back to my site that you linked and download the appropriate kernel binary and follow the direction on my site to install it and configure ext3.

The kernel binary that you can download at Mark Lord's site does not support ext3. What he meant in his original post is that if you download the hijack SOURCE from his site you don't have to patch the ext3 stuff from my site in. But, the binary he distributes does not have ext3 enabled.

-Mike

In reply to:

---

I should think Mark would chime in, being the file system stud he is :-)

---

I don't want to understate Mark's studliness, but I believe he is more of a driver stud that a filesystem stud. At least I didn't see his name that much while poking around all the fs code to get ext3 working.

As far as who should consider ext3, well it is probably most useful to developers, but I think it will get more and more important to regular users as hard drives get bigger. We've already got people on this board with 120G empegs. How long does that take to fsck? 3, maybe 4 hours?

-Mike

as a side note... if you decide to apply the hijack-ext3 kernel... fscking the root partition (with the updated e2fsck ) or stock fsck.ext2 gives the error:
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

i had to use the stock fsck to do it.

We've already got people on this board with 120G empegs.

Right.
And the next jump in mobile hard drive capacity is probably going to be 80GB or 100GB GB.
Put those in your empeg and fsk 'em.
It would take d_mn near all day.

In reply to:

---

fscking the root partition (with the updated e2fsck ) or stock fsck.ext2 gives the error:

---

Hmmm, I have not had that problem and I am sure I have fsck'd my root partition quite a few times since I started running ext3. Can anybody else confirm this? If you fsck it again with the newer fsck do you still get that error?

-Mike

its the newer fsck that gives problems. i have to use the backup fsck.old to do it.

In reply to:

---

its the newer fsck that gives problems. i have to use the backup fsck.old to do it.

---

Works for me...

empeg:/bin# fsck -f /dev/hda5
e2fsck 1.29 (24-Sep-2002)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/hda5: 1526/4096 files (0.5% non-contiguous), 11331/16384 blocks

Are you doing 'fsck /' maybe? Does that work with the stock fsck?

-Mike

So are they searching you at random and you just happened to be picked every time, or is it because you're canadian, or did they somehow actually connect your name to "Hijack"?

I believe the admin can specify the desired size for the journal file to just about any size wanted.

In reply to:

---

Works for me...

---

yeah, tried it and it works for me too.

mr. tfabris, may i suggest changing the faq entry from fsck -fay / (which works using the old fsck) to what it should be.

may i suggest changing the faq entry

I don't understand. I just used that FAQ text recently, and it worked perfectly.

yeah, it works with the stock fsck utility on a stock filesystem... but if you decide to use an updated version of fsck (like the one on mcomb's ext3 page), it wont work anymore. gives the error above.

This is from the e2fsck manpage on my machine,

-a This option does the same thing as the -p option. It is provided for backwards compatibility only; it is suggested that people use -p option whenever possible.

Perhaps his version is newer and has dropped the -a support.

Edit: clearly I haven't been reading the thread at all.

"fsck -fay /" fails, because /etc/fstab still contains 'ext2' as the filesystem. However when you use "fsck -fay /dev/hda5" it won't look at the fstab, but use whatever filesystem it can derive from the superblock, i.e. ext3.