[MLUG] A mini blog about file systems.

[Leslie Satenstein]

I was reading an article today about drawbacks in various file systems such as ext2, ext3, ext4, lvm, and btfrs.  The author, in my view was worried about using the latter two. 

Here is my response.  Kick me if I am wrong..





	
	
	
	
	
	

Lets look at the types of file systems
from another aspect with regard to ext2, ext3, ext4, lvm, and btfrs.



Home /laptop computer
If I have a small desktop computer with
perhaps 512megs of memory and an 80 gig drive, what do I want to have
loaded in memory so as to have the maximum amount of free memory
available for my application?  As a second part of this question, am
I running a time sharing service with financial data? Does every
small computer limit itself to one user running a small database and
some other stuff, where the swap file is kept inactive?  So, to
answer, perhaps ext3 is ideal.



Small Small business system
Now lets look at the intermediate sized
system, (lots of memory with all data on one disk).  Here we can
safely say that we want some speed, and we want disk I/O
re-sequencing to permit improved response times. This option is great
(and assume we have the 2008 technology for PC's with 4 gigs of
memory max). Some caching would be advantageous, would it not?  But
again, we want to preserve as much ram as possible for applications,
and as little extra for the kernel.  Would EXT4 be best? That is my
thought.






Next case, (I did not exhaust all the
cases. There are many I left out)



The humongous data store.



We have terabytes of data, we require
fast response time, and we require data to be shared over several
hard disks.  What do we do?



Do we create sub-directory links from
root to the other hard disks? Do we use logical volume
management(lvm) to allow one directory to be mapped to several hard
disks, with lvm restrictions, or do we use btfrs?  Btfrs is the file
system that is geared to larger CPU systems with very large data
storage requirements, and with simpler management to controlling
where extents will be placed. BTFRS in theory will replace LVM. LVM
currently is updated with ext3. 




So, now, lets look at SSD devices,
which we believe will replace hard disks as the active store, and
which I believe in the near future, will use the hard disk as a log
file device for recovery, or as an archive device. Do we as yet know
if we require btfrs, or ext4 or another "not yet designed" 
set of software drivers?



For very very large data stores, would
it be reasonable to have a dedicated file-server. Would it actually
be a battery powered CPU acting as both ssd and disk controller?  We
communicate with the data store via this CPU (device). It is
responsible for safely storing and retrieving data, and for allowing
multiple clusters of systems to interface to the common set of data.



In a banking or other critical
application, such as airline controllers at a busy airport, 

we need the backup system to take over
in a second or two after a main system failure. 

Which file system would permit this
activity?



Well, from what I read, none of ext3,
ext4, or even btfrs do allow this. So we need something new.  




For what it is worth, IBM solved this
problem around 1980, or before, with their mainframe systems.  







Finally, in the articles I read, the
new hard disks come with 16megs or even 32 megs of cache memory.  Not
one author has been written about using ext[234], lvm or btfrs with
these devices.



Your thoughts please.



Leslie



PS. Some IBM's raid controllers contain
a cache memory with battery backup. If there is a restart following a
crash, the controller card takes precedence over the hard disk
contents. The logic behind this is to permit the use of caching
hard-disk devices, with full recovery possibilities. Now, with the
cache at the hard disk level, but battery backed up, we realize that
we don't require 4 or 5 second delays and large caches in the Linux
disk drivers.  

  





-------------
Regards  
Leslie
 Leslie Satenstein
5752 Avenue Lockwood.
Cote St. Luc Montreal Quebec H4W 1Y9  Canada
voice:  514-369-1685    
mailto:lsatenstein at yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mlug-listserv.mlug.ca/attachments/20090322/436632a7/attachment.htm