UFS filesystem size limit

[Wiger van Houten]

I would like to add an option for encrypting the filesystem to that list,  
that would be REALLY welcome too ;).



On Sat, 03 Sep 2005 23:54:49 +0200, Andreas Hauser <andy at xxxxxxxxxxxxxxx>  
wrote:

dillon wrote @ Sat, 3 Sep 2005 09:49:03 -0700 (PDT):

    A friend of mine swears by linux, but curses just about every  
filesystem
    he tries (and curses UFS as well).  Linux FS's have a lot of hype  
but
    the only thing that they really have going for them is the 'instant
    reboot' feature... if you trust them enough, that is.  Reiser is
    unbelievably sensitive to disk errors, to the point where you can  
lose
    the whole filesystem when something unexpected happens.  JFS has  
poor
    performance.  etc etc.  Linux filesystems are not poster childs.
    Frankly, anyone who feels a need to put a million files into a  
single
    directory gets when they deserve.
For the trust, ext2, ext3 and UFS play in one league for me, when i use
the problems, i had with them, as a basis.
Well JFS uses less CPU than XFS, which will make it faster on a busy  
server.
But let's not forget, XFS and JFS were not native but imported and
somehow degraded a bit on the move.

Some aggregation would certainly be nice though (less but better  
filesystems)
and with better licenses for sharing with us :)

If the hardware dies on you you can not trust the FS anymore anyways.
Getting your backups is the much more secure and often faster way.
Hiding the disk problems is not really helping, when with todays  
hardware,
you can be pretty sure it will certainly die.

    There are two things I want for UFS:  (1) Nearly instant reboots
    (without having to depend on softupdates), and (2) an ability to  
grow
    or shrink the filesystem.  Both are quite achievable goals.


The most intersting points in the filesystem area for me are:

* Snapshots
  This finally makes backups atomic
  -> no more "file has changed while backuping".
  Second it makes it easy to make the backups available to the users  
[1], like
  "/var/backup/${YEAR}/${MONTH}/${DAY}" or as some have it "./.snapshot".
  -> no more "I just deleted this file. Can you restore it?"

* Journaling
  If this works out how i hope, then it will be easy to mirror  
everything to
  a failover sever. No more expensive rsync(1)s or complex mail setups to
  get the mail to the backup mirror. Fast recovery after a crash is nice
  too, but then it shouldn't crash in the first place ;) In high
  availability scenarious you probably prefer the fail over server,
  especially since you want to debug the crash. So 5 minutes for
  fsck or log replay are OK for me, need not be instant.

* volume management
  Growing and shrinking are not so interesting but hot-plugging in  
another
  disk and extending a life FS that would be great, need not be as  
complex
  as vinum though. I always liked how that works on True64 (or what's the
  nom du jour). Like "mkdir volume1 && cd volume1 && ln -s /dev/disk1 .   
&&
  ln -s /dev/disk2 .", there you go.

* Networked FS
  ClusterFS Like GFS or Lustre are interesing and not only for computing
  clusters, e.g. we have 4-8 NFS servers serve one shared GFS here for  
the
  Homedirs. I am not sure if the journaling can enable such things but  
afair
  you said something in the direction.
  NFS4[2] is something i badly want and i am sure a year down the road  
this will
  be a hard requirement at many places. I always imagined i could just
  export my /usr/ports and most problems with ports would have gone away  
;)

* excessive usage
  Zettabyte filesystems with a trillion files per dir would be nice :-)
  In the cluster area such things are needed. Look at the problems the  
CERN
  has with the amount of data coming out of the LHC[3].

Andy

[1]
This really well done in plan9:
http://cm.bell-labs.com/magic/man2html/4/fossil
[2]
There are patches for nearly all BSD systems out there:
ftp://ftp.cis.uoguelph.ca/pub/nfsv4
Though Jeff thinks the OpenSolaris implementation is the better way to  
go.

[3]
http://public.web.cern.ch/Public/Content/Chapters/AboutCERN/CERNFuture/WhatLHC/WhatLHC-en.html


--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/