Re: journaling and devel [was Re: Development Setups]

Re: journaling and devel [was Re: Development Setups]

[Andreas Dilger]

Pavel writes:
> I disagree.. With journal filesystem, when something is silently corrupting
> your disk, you'll never know.  With ext2, you sometimes sync & reset to make
> sure your disks are still healthy.  I would not recomment journaling on
> experimental boxes.

I would say just the opposite with ext3 - I prefer to use it on my development
boxes.

1) No fsck time (normally) after crashing, which can happen a lot.
2) You can set ext3 to fsck automatically after a fixed number of reboots/time
   if you are worried about a bad disk/cable/kernel.

Most of the mke2fs which support ext3 (1.20+ or so) will set the check
interval to 20 + rand(20) reboots per check by default, or 6 months.  Since
this is a random value, you don't get all of your filesystems checked at the
same time, but it happens at least once in a while to ensure that each fs is
OK.

Of course, you can turn it off if you want, but the option is there to do
periodic checks.  The time interval is probably still a good idea, even if
you turn of the per-N-mount checking, because of bit rot, etc.

Cheers, Andreas
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Development Setups

[Adam Keys]

As a budding kernel hacker looking to cut my teeth, I've become curious about 
what types of setups people hack the kernel with.  I am very interested in 
descriptions of the computers you hack the kernel with and their use patterns.

I was thinking of starting with a modern machine for developing/compiling on, 
and then older machine(s) for testing.  This way I would not risk losing data 
if I oops or somesuch.  Alternately, is there a common practice of using lilo 
to create development and testing kernel command lines?  Is this a useful 
thing to do or is it too much of brain drain to switch between hacking and 
testing mindsets?

Instead of having separate machines,  there is the possibility of using the 
Usermode port.  As I understand it this lags behind the -ac and linus kernels 
so it would be hard to test things like the new VM's.  Usermode would not be 
suitable for driver development either.  Again, thoughts on this mode of 
development?

Which brings me to the final question.  Is there any reason to choose 
architecture A over architecture B for any reason besides arch-specific 
development in the kernel or for device drivers?

AKK

-- 
Adam K. Keys
<adam.keys@HOTARD.engr.smu.edu> (Remove the HOTARD to email me)

Re: Development Setups

[David Woodhouse]

adam.keys@engr.smu.edu said:
> I was thinking of starting with a modern machine for developing/
> compiling on,  and then older machine(s) for testing.  This way I
> would not risk losing data  if I oops or somesuch. 

With journalling filesystems you needn't worry _too_ much about losing 
data; depending of course on what you're hacking on. Having two separate 
boxen for development and testing is mostly valuable because you can keep 
working when you break it - it doesn't take your entire desktop environment 
down with it.


adam.keys@engr.smu.edu said:
>  Which brings me to the final question.  Is there any reason to choose
>  architecture A over architecture B for any reason besides
> arch-specific  development in the kernel or for device drivers?

If you're developing device drivers and have the choice, pick something 
esoteric to enforce good behaviour. Something which does out-of-order 
stores, has non-cache-coherent DMA, is big-endian and preferably 64-bit. I 
think both mips64 and sparc64 boards can meet all those criteria - if not, 
get as close as you can. 

--
dwmw2

journaling and devel [was Re: Development Setups]

[Pavel Machek]

Hi!

> > I was thinking of starting with a modern machine for developing/
> > compiling on,  and then older machine(s) for testing.  This way I
> > would not risk losing data  if I oops or somesuch. 
> 
> With journalling filesystems you needn't worry _too_ much about losing 
> data; depending of course on what you're hacking on. Having two separate 
> boxen for development and testing is mostly valuable because you can keep 
> working when you break it - it doesn't take your entire desktop environment 
> down with it.

I disagree.. With journal filesystem, when something is silently corrupting
your disk, you'll never know. With ext2, you sometimes sync & reset to make
sure your disks are still healthy. I would not recommend journaling on 
experimental boxes.
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: journaling and devel [was Re: Development Setups]

[Steve Lord]

> 
> I disagree.. With journal filesystem, when something is silently corrupting
> your disk, you'll never know. With ext2, you sometimes sync & reset to make
> sure your disks are still healthy. I would not recommend journaling on 
> experimental boxes.
> 								Pavel

On the otherhand I have found the main problem with using XFS on development
platforms is that you do not test the kernel shutdown code very much.
It is much faster to just reset the box than to do a shutdown, and it
does not make a difference when you bring it back up.

Steve