Design my own file system

[Yadagiri Rao KP]

Sir,
How to design a file system that allows heirarchy of directories and
files in those directories.

Basically the file system should work similarly like unix or linux or
windows file system but using java as the main core language.



Any ideas.....
Ple share with me
Regards
Yadagiri

 

[Shripathi Kamath]

Sir,
How to design a file system that allows heirarchy of directories and
files in those directories.

Basically the file system should work similarly like unix or linux or
windows file system but using java as the main core language.



Any ideas.....
Ple share with me
Regards
Yadagiri

Linux and BSD are open-sourced OSes that support filesystems. (with
appropriates licenses, of course)

A straightforward way of doing what you want is to port the C code for, say,
the Ext2 file-system in Java. You will have some native code to write as
well to interface with the storage hardware.

HTH,

 

[Tim Tyler]

:[email protected] (Yadagiri Rao KP) wrote or quoted :

:>How to design a file system that allows heirarchy of directories and
:>files in those directories.

: see http://mindprod.com/projjavafilesystem.html

I don't think a 10 gigabyte file is a sensible implementation plan -
too much chance of damage.

 

[Roedy Green]

I don't think a 10 gigabyte file is a sensible implementation plan -
too much chance of damage.

Presumably your own implementation is more robust than the host
system's.

There are two things that can go wrong at the host level:

1. directory wrecked

2. track becomes unreadable.

The fewer directory entries you have, the less your odds of being
hurt. On the other hand, if you have two directory entries and lose
one, you still have half your data, probably not all that useful.

The damage from a lost track is the same, presuming your OS lets you
recover the rest of the file.

 

[Tim Tyler]

:>I don't think a 10 gigabyte file is a sensible implementation plan -
:>too much chance of damage.

: Presumably your own implementation is more robust than the host
: system's.

: There are two things that can go wrong at the host level:

: 1. directory wrecked

: 2. track becomes unreadable.

: The fewer directory entries you have, the less your odds of being
: hurt. [...]

Surely a rather minor effect.

: On the other hand, if you have two directory entries and lose
: one, you still have half your data, probably not all that useful.

Probably a /lot/ better than nothing ;-)

: The damage from a lost track is the same, presuming your OS lets you
: recover the rest of the file.

Check what databases do. They almost invariably use multiple files -
rather than one big one. It's a more robust solution - if the
power is lost in the middle of a write operation, the damage is
more likely to be localised.

Indeed, a database would make a reasonable foundation for a modern
filing system.

 

[Roedy Green]

Indeed, a database would make a reasonable foundation for a modern
filing system.

Yes, definitely. It seems so odd you can't even rapidly find a file
by name rather than directory.

The plan I had in my student project was to get your file system going
hosted by some other OS. Eventually you could let it interface
directly with the hardware, taking over at least an entire partition.

At that point you don't really get a choice. You are one big file.

 

[Sudsy]

FISH wrote:

Didn't Oracle try and push an idea like that a few years back?

(Did anything come of it, or was it just more hot air from Larry?)


-FISH- ><>

JFS (Journaled File System) uses database concepts to provide a more
robust implementation. I recall that checking a JFS on AIX was much
faster than running fsck. Repairs were also very quick.
IIRC there's even a JFS implementation for Linux, although I have no
personal experience with it so cannot say how well it works.

 

[Roedy Green]

JFS (Journaled File System) uses database concepts

NTFS uses transactions to update some system structures. That is why
the disk rarely is corrupt after a crash.

 

[Michiel Konstapel]

FISH wrote:


JFS (Journaled File System) uses database concepts to provide a more
robust implementation. I recall that checking a JFS on AIX was much
faster than running fsck. Repairs were also very quick.
IIRC there's even a JFS implementation for Linux, although I have no
personal experience with it so cannot say how well it works.

Yup, ext3 supports journalling, as do XFS and some others. The server I
co-own runs on it and well, it works fine. Saved a lot of time when it
had to check a 120 GB RAID array...
Michiel

 

[FISH]

FISH wrote:


JFS (Journaled File System) uses database concepts to provide a more
robust implementation. I recall that checking a JFS on AIX was much
faster than running fsck. Repairs were also very quick.
IIRC there's even a JFS implementation for Linux, although I have no
personal experience with it so cannot say how well it works.

I seem to recall what Oracle was talking about was replacing the
filesystem, as we know it, entirely with a database. I don't recall
reading anything about it myself, but I do remember listening to some
Oracle DBA's discussing it as if it was the 'next big thing' (tm).

This would have been back in the days when Oracle was loundly banging
the drum for replacing desktop PCs with thin clients as a vision of
the future (an idea which is close to Sun's heart too!). In such a
disk-less environment (diskless for the end-user anyway!) storing and
retrieving your work as records on a remote database might have been
an interesting idea. Could you imagine no longer having directories,
but 'views' which enable you to cluster related material ('files')
together in many different ways, some static and some ad-hoc, based
upon different search/sort criteria? As new material was saved/
removed from the database, it would automatically be added/removed
from the views it qualified for. So your 'filesystem' is no longer
based upon the physical location of any data on a disk, but fluidly
created based upon the content, type and format of the data itself.


-FISH- ><>