On Mon, 2003-04-07 at 19:39, Norbert Cartagena wrote:
> > You REALLY DON'T want to make it FAT32 native under Linux. The
> > fileserver is your best option.
> >
>
>
> ICH!!! Unfortunatelly, doing that isn't an option at the moment. Since I
Because... ? Funding? Technology? Just curious...
> don't think I'll be writing anything to it from windows, anyways (think
> glorified game box with VPN functionality), I think I might just make it
> Ext3 and use the explore2fs tool, which Jay suggested. *Sigh* Oh well.
Then Good Luck!
MAKE SURE you don't "mount" it as ext2 from the Windows side if you
haven't done a clean shutdown as ext3! If you mess with ext2
filesystems that have an un-committed ext3 journal, you can severly
corrupt the filesystem.
> > P.S. SGI's XFS rocks all over other Linux journaling FSs.
> >
>
> Excuse the heavy brow, but why?
Performance and reliability. Just two.
XFS is extremely good at scheduling reads and writes so that they get
maximum performance for each one. Individually, I have seen amazing
performance from XFS filesystems, but also since it's designed from the
beginning as a "media" filesystem, it's very good at doing things like
streaming multiple simultaneous video feeds off of a filesystem with QoS
on each stream. ReiserFS, while very good, has a tendency in my
experience to starve reads for pending writes; it will cache until the
cache is full, and block all I/O until the cache is flushed. It makes
it very bursty. XFS can easily handle lots of simultaneous reads and
writes and is very good at scheduling them all so no individual process
gets starved for I/O. Recent releases of XFS have eliminated its
biggest performance bottleneck compared to other filesystems which had
been that deletes were performed synchronously.
XFS has a long history at SGI, so there is a large volume of diagnostic
information for XFS crashes and the XFS recovery tools are VERY good.
(Plus if you watch the lists long enough, nearly every reported crash
has resulted from hardware failures or someone doing something stupid.
The few remaining have generally been things like people using shared
fibre-channel arrays to do multi-terabyte filesystems on massive
hardware and running into VERY obscure XFS bugs that nearly immediately
get fixed.) I've lost a couple of ReiserFS filesystems, and at one
point even the manpage for reiserfsck said something to the effect of
"if you're using this tool, you're almost certainly SOL." I haven't
actually lost an XFS filesystem yet other than to hardware problems, and
while testing here a couple of years ago at NKS to see if it was
reliable enough to go production, I did some really nasty things to XFS
to try to make it break.
I'm not knocking on ReiserFS in any way, it's just that XFS, in my own
personal and professional experience (we've been all-XFS at NKS for
probably over a year now, on at least dozens if not hundreds of
machines) that it's the best journaling filesystem on Linux right now in
terms of performance and reliability.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
#!/usr/bin/perl -w
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map
{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;
$t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)
[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join
"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*
8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}
print+x"C*",@a}';s/x/pack+/g;eval
usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \
| extract_mpeg2 | mpeg2dec -
http://www.cs.cmu.edu/~dst/DeCSS/Gallery/
http://www.eff.org/ http://www.anti-dmca.org/
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 18:00:58 EDT