Welcome to the MacNN Forums.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

You are here: MacNN Forums > Software - Troubleshooting and Discussion > macOS > Modern filesystem

Modern filesystem
Thread Tools
OreoCookie
Moderator
Join Date: May 2001
Location: Hilbert space
Status: Offline
Reply With Quote
Mar 24, 2002, 10:33 AM
 
What would you want to see in the next-gen filesystem for OS X.

Here are two suggestions.

1. A journaling filesystem that repairs its damages by itself. No need for booting from a CD and use the Disk Utility.

2. A database that stores and registers the files for you. You can find your files, e-mails or whatever a lot faster. The index is updated in the background (thanks to preemptive multitasking).

What do you think about it?
I don't suffer from insanity, I enjoy every minute of it.
     
JLL
Professional Poster
Join Date: Apr 1999
Location: Copenhagen, Denmark
Status: Offline
Reply With Quote
Mar 24, 2002, 11:16 AM
 
Originally posted by OreoCookie:
<STRONG>2. A database that stores and registers the files for you. You can find your files, e-mails or whatever a lot faster. The index is updated in the background (thanks to preemptive multitasking). </STRONG>
Mac OS X has a locate command which uses a locate database.

Locator is a GUI to the command.
JLL

- My opinions may have changed, but not the fact that I am right.
     
Millennium
Clinically Insane
Join Date: Nov 1999
Status: Offline
Reply With Quote
Mar 24, 2002, 11:28 AM
 
Sounds like what you want is Be's filing system.

But all the same, Be's filesystem lacks one very important feature of HFS+: unique file ID's.

The reason these ID's are important is because with HFS+, the ID is what the computer uses when looking for the file, not the filename (which is basically window-dressing for the user). This ID never changes, even when the filename is changed (with one exception: a file which is copied over an existing file will take on the ID of the old file).

Why is this important? Because this is where very nearly all of the usability advantages of HFS+ have their roots. Aliases refer to this ID, not the filename; this is why they don't break when you move or rename the file. Most -though not all- of the old MacOS API's (and Carbon's by extension) refer to files by ID, for the same reason (and those which refer to files by name and path have a good reason for it, like loading only Extensions that are in the Extensions Folder so that you have an easy way to disable them). Be was considering implementing these in their filesystem, but decided not to for some utterly unfathomable reason.

It's not possible to create a filesystem which repairs itself. To do so would require it to be able to detect its own errors, and uncertainty comes into play here; as you observe a filesystem, it changes slightly. What can be done, though, is creating a filesystem which does not get damaged; this is where joirnaling and softupdates come into play. They can't safeguard against individual files being corrupted, but they can make certain the filesystem itself will not be.
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
     
voodoo
Posting Junkie
Join Date: Mar 2001
Location: Salamanca, EspaƱa
Status: Offline
Reply With Quote
Mar 24, 2002, 11:31 AM
 
Why is OS X much slower than OS 9 when finding files? OS 9 uses a database to find files, that much I know. And yet OS X takes much longer to find anything. The HD churns and scratches like when a Wintel PeeCee is searching for a file and they don't use a DB.
I could take Sean Connery in a fight... I could definitely take him.
     
Developer
Addicted to MacNN
Join Date: Apr 2001
Location: europe
Status: Offline
Reply With Quote
Mar 24, 2002, 01:09 PM
 
Arbitrary meta data support.
Nasrudin sat on a river bank when someone shouted to him from the opposite side: "Hey! how do I get across?" "You are across!" Nasrudin shouted back.
     
OreoCookie  (op)
Moderator
Join Date: May 2001
Location: Hilbert space
Status: Offline
Reply With Quote
Mar 24, 2002, 01:23 PM
 
&lt;--- quote ---&gt;

It's not possible to create a filesystem which repairs itself. To do so would require it to be able to detect its own errors, and uncertainty comes into play here; as you observe a filesystem, it changes slightly. What can be done, though, is creating a filesystem which does not get damaged; this is where joirnaling and softupdates come into play. They can't safeguard against individual files being corrupted, but they can make certain the filesystem itself will not be.

&lt;--- end quote ---&gt;

There are several filesystems that detect incoherencies by themselves. BeFS, ReiserFS, and XFS are three popular examples. During startup they are checked whether or not the data is coherent with the journal and repairs it if necessary.
Such a check maybe invoked manually, too.


&lt;--- quote ---&gt;

Mac OS X has a locate command which uses a locate database.

&lt;--- end quote ---&gt;

I know it does, but that is not what I mean.
What I am thinking of is a database that really disguises the *real* location of a file to some extent. E. g. it does not matter if it is located on the server or somewhere in the net. The database knows where the file is and about its contents, too.
If you want to get all the e-mails and word documents that deal with the repair of your iBook, your query is simply 'repair iBook'. The database checks all files, no matter if it is an e-mail or a word document. All related documents may show up, the results are *structured*. E. g. you could sort it by logical order (first initial e-mail, then the reply, ...).
If you save a file, it is automatically indexed and added to the database 'on the fly'.

What I mean is that if you are an 'average' user who wrote a letter to grannie about something, will (s)he be able to find it right away after a year or so?
Or if you have many, many files on the computer, will you be able to find a specific letter to someone by its contents? Takes some time (on the office computer, we have several thousand letters ...).

The difference is that the database *is* the filesystem instead of a database that runs *on* a filesystem.
In that way, it does more than BeFS.

Wouldn't that be a major leap forward?
I don't suffer from insanity, I enjoy every minute of it.
     
bradoesch
Professional Poster
Join Date: Jun 2000
Status: Offline
Reply With Quote
Mar 24, 2002, 02:52 PM
 
Originally posted by voodoo:
<STRONG>Why is OS X much slower than OS 9 when finding files? OS 9 uses a database to find files, that much I know. And yet OS X takes much longer to find anything. The HD churns and scratches like when a Wintel PeeCee is searching for a file and they don't use a DB.</STRONG>
That's funny. I find that OS X finishes it's search much faster than OS 9. But I will agree with you that PCs take even longer...stupid things.
     
man0
Junior Member
Join Date: Jan 2002
Status: Offline
Reply With Quote
Mar 24, 2002, 07:57 PM
 
i would like to see something similar to ext3 or ReiserFS too...journaled filesystem for everyone!!! )
------&gt;man0
     
dawho9
Senior User
Join Date: Mar 2001
Location: Crystal, MN
Status: Offline
Reply With Quote
Mar 24, 2002, 09:15 PM
 
To throw this one out as an example, but Novell has this with their NetWare file system.

Auto Volume repair if errors occur during mounting, database like options with NSS volumes.

And it has unique file ID's, as everything is based on unique ID's to work with their overpowerful NDS database.

It works well, but I don't think we will ever see anything like this for OSX.

dw9
- Intel iMac 20' Core Duo - 1GB RAM
- Technology Blog) http://portalxp.org/Web/blogs/rbrynteson/
     
SYN
Senior User
Join Date: Oct 2000
Location: Paris, France
Status: Offline
Reply With Quote
Mar 26, 2002, 06:20 PM
 
HFS+ has a lot of features that go unused by Apple.

It is 64 bit clean.
It supports extensible attributes.
It structure is perhaps even more database like than even BFS'

The only issue I have with it right now is that it isn't journaling. If Apple could implement in the OS all the features present in the FS, I'd be quite happy. Give me journaling as a bonus and I'll be set.

A while ago there was a job opening at Apple regarding FS implementation, journaling experience was required. That job is not available anymore. Maybe we can hope Apple is working on this... They really should if they want to cater to the biotech world.

Ideally, I'd like an FS similar to HFS+, with journaling, whose database like structruture and extensible attributes would be thoroughly leveraged, with guaranteed throughputs ala XFS, and live node-watching allowing for live file information update (imagine a get info window on a file being downloaded that displayed the size evolution, live, Disk icons that showed the free space live... this is already available in BeOS).

One can only hope...
Soyons Rļæ½alistes, Demandons l'impossible
     
IEEE1394
Mac Enthusiast
Join Date: Dec 2000
Status: Offline
Reply With Quote
Mar 26, 2002, 06:35 PM
 
Would throwing in a journaled FS greatly reduce boot times?
     
Millennium
Clinically Insane
Join Date: Nov 1999
Status: Offline
Reply With Quote
Mar 26, 2002, 07:51 PM
 
Originally posted by IEEE1394:
<STRONG>Would throwing in a journaled FS greatly reduce boot times?</STRONG>
Not really. It would be a great help after a crash (since you wouldn't need to [b]fsck[/d] the disk), but that would be pretty much it.

As for the "database-like structure" that SYN mentioned: this isn't really the case. Although it's true that HFS+ gets away from some of the "old standard" filesystem techniques (for example, there are no real folders in HFS and HFS+; what we see as folders are just constructs to make it more convenient for the user), the actual implementation of the system is very crude by today's database standards. The same B-Tree structure that makes file lookups so fast also forces serialized access to the filesystem, which slows everything else down. There is no query language, and not much in the way of search capability.

Besides which, some of the decades-old structures of HFS can be done better now. T&C would be better handled by Java-type identifiers for Creator and MIME types for the Type code (both are still necessary, but can be done better than with a cryptic four-character code).

Ultimately, Apple needs a clean break, filesystem-wise. It's a shame, because nondestructive conversion is a truly awesome thing, but I don't know how practical it is. And if they do switch systems, let's hope they remember to go forward, with superior systems like extensible metadata and named forks, rather than stick with a system where we haven't seen very nuch new since the days of te early Unix filesystems.
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
     
man0
Junior Member
Join Date: Jan 2002
Status: Offline
Reply With Quote
Mar 26, 2002, 09:09 PM
 
Originally posted by Millennium:
<STRONG>
Not really. It would be a great help after a crash (since you wouldn't need to [b]fsck[/d] the disk), but that would be pretty much it.

</STRONG>
Well some filesystems can reduce boot time ...and the time reduction is also really big.

Example Reiserfs read small files ( &lt;5kbytes ) 40 times faster than ext2 filesystems. and writes them 15 times faster if i am not wrong..but it's a bit slower than ext2 with bigger files..
------&gt;man0
     
Brass
Professional Poster
Join Date: Nov 2000
Location: Tasmania, Australia
Status: Offline
Reply With Quote
Mar 26, 2002, 10:56 PM
 
Originally posted by OreoCookie:
<STRONG>What would you want to see in the next-gen filesystem for OS X.

Here are two suggestions.

1. A journaling filesystem that repairs its damages by itself. No need for booting from a CD and use the Disk Utility.

2. A database that stores and registers the files for you. You can find your files, e-mails or whatever a lot faster. The index is updated in the background (thanks to preemptive multitasking).

What do you think about it?</STRONG>

Interestingly, Sun now provides the option of journalling (FS logging) for UFS filesystems. These are very basic file systems and if you can do it for UFS, then you should be able to do it for HFS plus, without using a new or different filesystem type.

Microsoft is working on a database filesystem to replace NTFS. It's an interesting idea, but just may prove to be too unstable. Time will tell.
     
me
Mac Enthusiast
Join Date: Jun 2000
Location: Seattle, WA
Status: Offline
Reply With Quote
Mar 26, 2002, 11:41 PM
 
I'm told that journaling file systems actually do writes faster, at least that's what my OS book tells me. I'm not too concerned about the new MS filesystem. A few reasons:

1) MS takes 3-5 tries to get anything right
2) programs have to be reworked to best utilize the FS
3) Half the stuff MS says they will release never makes the cut
4) Few buyers even know what a filesystem is, much less which one they want.
     
Millennium
Clinically Insane
Join Date: Nov 1999
Status: Offline
Reply With Quote
Mar 26, 2002, 11:59 PM
 
Originally posted by man0:
<STRONG>

Well some filesystems can reduce boot time ...and the time reduction is also really big.

Example Reiserfs read small files ( &lt;5kbytes ) 40 times faster than ext2 filesystems. and writes them 15 times faster if i am not wrong..but it's a bit slower than ext2 with bigger files..</STRONG>
Point taken. But most of that speed is simply due to the way the filesystem is laid out, and not the journaling aspect per se.

Journaling filesystems can be faster, under the right circumstances. For example, a heavily-loaded hard disk with lots of writes will benefit, because instead of there being many small writes, they'll be combined into one large write operation when the filesystem gets synced.

In most circumstances, the speed of a journaling depends on whether or not it journals all data or just metadata. Journaling all data is much slower, but it's also more robust, providing better protection against individual file corruption. Journaling just file metadata is much faster (less to write), and it still ensures that the filesystem itself will not get damaged, but individual files still might. Almost all journaling filesystems do the metadata-only approach, since there are other ways to protect against individual file corruption (RAID systems, or just plain backing stuff up). A few give the option of full-data journaling, but I wouldn't recommend this for HFS+, since it requires far bigger iron than a Mac just to run at an acceptable speed, and the last thing OSX needs is more speed bottlenecks.
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
     
OreoCookie  (op)
Moderator
Join Date: May 2001
Location: Hilbert space
Status: Offline
Reply With Quote
Mar 27, 2002, 05:26 AM
 
I have posted the question, because I have read that MS plans to replace NTFS with a probably cut-down version of its MSQL relational database, as some of you have posted. I agree that MS usually don't live up to the expectations they imposed on themselves.

Anyway. I have also read some articles that Apple already works on a new filesystem. This should be relatively easy to implement, because OS X has an abstraction layer for the filesystem -- all Apple has to do is write a new driver for it ...

I think you guys restrict your discussion to the journaling part which is more or less transparent and offers 'little benefit' in the sense that it doesn't offer a radical new approach to things.

What I am interested in is the fact that files may have a relationship which is recorded into the filesystem. For example if you write an e-mail, the response will be marked related. Or if you have a document template, then this template is related to all the documents used.

Imagine you could sort the documents by 'heritage' or look at them in terms of 'relationships'. 'Folders' as such won't be needed any longer. Imagine you could have sorted the same amount of files in any different way without changing the layout of the filesystem (i. e. the actual 'folder structure').
Maybe one user (e. g. in the office) prefers another sorting of the files, then (s)he can do so without actually changing anything for the others.

What do you think about the database aspect?
I don't suffer from insanity, I enjoy every minute of it.
     
KellyHogan
Banned
Join Date: Oct 2001
Location: The Breakaway Democratic Banana Republic of Jakichanistan.
Status: Offline
Reply With Quote
Mar 27, 2002, 06:01 AM
 
Originally posted by bradoesch:
<STRONG>

That's funny. I find that OS X finishes it's search much faster than OS 9. But I will agree with you that PCs take even longer...stupid things.</STRONG>
How long it takes is completely dependent on how much data is on the drive. OS9 would be faster than Windows or OSX simply because it is a leaner OS (think how many advanced technologies are missing).
     
sjk
Forum Regular
Join Date: Feb 2002
Location: Hawaii
Status: Offline
Reply With Quote
Mar 27, 2002, 10:05 PM
 
Originally posted by OreoCookie:
<STRONG>[...]
Imagine you could sort the documents by 'heritage' or look at them in terms of 'relationships'. 'Folders' as such won't be needed any longer. Imagine you could have sorted the same amount of files in any different way without changing the layout of the filesystem (i. e. the actual 'folder structure').
Maybe one user (e. g. in the office) prefers another sorting of the files, then (s)he can do so without actually changing anything for the others.

What do you think about the database aspect?</STRONG>
Is the idea to create databases on which "arbitrary" data abstractions (filesystems being just one example) will optimally co-exist? It's already clear that traditional filesystems aren't ideal for certain types of data management so databases are built without relying on them. Is there filesystem-centric design in storage devices that would change?

The growing explosion of information is overwhelming data organization strategies like files/folders. An "average" computer user would rather not care about location-dependent details like filenames, URLs, etc. What are better alternatives to organizing/naming/referencing data?

Mumble, mumble.

[ 03-27-2002: Message edited by: sjk ]
     
himself
Mac Elite
Join Date: Jan 2002
Location: Live at the BBQ
Status: Offline
Reply With Quote
Mar 28, 2002, 12:54 AM
 
Originally posted by sjk:
<STRONG>...What are better alternatives to organizing/naming/referencing data?

Mumble, mumble.
</STRONG>
I honestly don't know too much about this filesystem business, but I do know just enough for it to interest me... I've found something that works somewhat similar to what OreoCookie was describing, but it's alittle less arbitrary. I use Stuffit Deluxe a lot, and I was really taken at how easy it is to move files in and out of "archives," where files are arranged into a grouping, something like a glorified folder... but what if you had an FS that would "archive" (not necessarily compress, but group) files on the fly based on attributes and criteria the user specifies. This archive that you've built would be extremely portable... and extensible, and modular... how does this sound? or am I saying what everyone else has been saying all along?
"Bill Gates can't guarantee Windows... how can you guarantee my safety?"
-John Crichton
     
OreoCookie  (op)
Moderator
Join Date: May 2001
Location: Hilbert space
Status: Offline
Reply With Quote
Mar 28, 2002, 05:28 AM
 
The idea behind it is that instead of treating files (i. e. 'raw' data), information (such as contacts and addresses), and relations between them (right now just 'folders' that group the information) differently, a database structure combines all of them.
In that way the barriers between them dissolve, making the computer more usable. All you look for is information, not a 'file' as such (files are just packages of information such that an app can handle it). The database approach offers one interface that let's you do all of the tasks currently handled by different applications.

It would be a great advance, because it makes looking for information more transparent.

When you look for the address a person, it would be possible that first, your addresses are searched, then a website. You get a result, not knowing, where it came from. But maybe your machine finds it in the head of a letter. That is what I mean -- look for everything in one place.

Another interesting aspect is that 'files' available over the network could be treated as local files.

So I think sjk has gotten it right:

&lt;--- quote ---&gt;

Is the idea to create databases on which "arbitrary" data abstractions (filesystems being just one example) will optimally co-exist? It's already clear that traditional filesystems aren't ideal for certain types of data management so databases are built without relying on them. Is there filesystem-centric design in storage devices that would change?

&lt;--- end quote ---&gt;

The database stores the information in chunks such that it can be viewed as 'files' (e. g. for the underlying core OS), but on the other hand, all the advantages I wrote about before can be used as well (on the user and app level).
I don't suffer from insanity, I enjoy every minute of it.
     
sjk
Forum Regular
Join Date: Feb 2002
Location: Hawaii
Status: Offline
Reply With Quote
Mar 30, 2002, 06:31 PM
 
     
Millennium
Clinically Insane
Join Date: Nov 1999
Status: Offline
Reply With Quote
Mar 31, 2002, 01:31 AM
 
People seem to think that this "database-based filesystem" is some kind of magical panacea which will make all kinds of computing much easier in the future.

Indeed, database-based filesystems do have a great deal of potential. But in order to use any of it, you have to have an interface to it; otherwise, it is useless.

Why do I bring this up? Because for all of the power of BFS, its interface for the database stuff was a query language. Not SQL, but vaguely similar. In other words, typing in code. How is that good interface? Yeah, for power users it was great stuff, but for the average user it was no better than the current hierarchical file/folder structure.

My point: database-based filesystems are only half the battle, as far as that sort of thing is concerned. You have to make the new functionality easy to use, or you've gained nothing. You need an interface to make a database-based filesystem work. So it would be a lot more productive for people to stop clamoring about just wanting a database-based system, and instead start coming up for ideas of an interface to make it work with the user.
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
     
Smircle
Forum Regular
Join Date: Feb 2001
Location: Berlin, .de
Status: Offline
Reply With Quote
Mar 31, 2002, 07:20 AM
 
Originally posted by OreoCookie:
The difference is that the database *is* the filesystem instead of a database that runs *on* a filesystem.
In that way, it does more than BeFS.

Wouldn't that be a major leap forward?
I am not sure. I am not a DB specialist, but from my experience working with relational databases, I would say they are very effective at finding data when complex conditions have to be met (surely faster than a traditional file system) but not when it comes to raw throughput performance on simple things like "store 1000 file in that folder".

I suspect, boot times would go through the roof - likewise for applications swapping out tons of data pieces (think photoshop).

Funny you bring this up, I myself have been phantasizing about this at times - it would make some things really much more powerful.
     
wingdo
Senior User
Join Date: Apr 2001
Location: Chicago, Earth
Status: Offline
Reply With Quote
Mar 31, 2002, 12:38 PM
 
Originally posted by OreoCookie:
<STRONG>
There are several filesystems that detect incoherencies by themselves. BeFS, ReiserFS, and XFS are three popular examples. During startup they are checked whether or not the data is coherent with the journal and repairs it if necessary.
</STRONG>
Yes, but with OS X, how often are you restarting your Mac? The only time I ever restart is when a software install tells me I have to.
MBP - 2.33GHz C2D, 3GB RAM, 256MB VRAM, 160GB HD
PB - 1.5GHz G4, 2GB RAM, 128MB VRAM, 80GB HD
PM - Dual 1GHzG4, 1.5GB RAM, NVidia GForce 3, 2x 80 GB HD
     
krove
Mac Elite
Join Date: Jul 2000
Location: Washington, DC
Status: Offline
Reply With Quote
Mar 31, 2002, 02:46 PM
 
Originally posted by sjk:
<STRONG>Interesting:

Dominic Giampaolo joins Apple</STRONG>
Woohoo! Here's hoping to a more modern FS in the next major revisioon after 10.2 (or 10.5?)!


How did it come to this? Goodbye PowerPC. | sensory output
     
OreoCookie  (op)
Moderator
Join Date: May 2001
Location: Hilbert space
Status: Offline
Reply With Quote
Apr 1, 2002, 01:22 PM
 
I agree that such technology has to be implemented, otherwise it is worthless.

I could picture having an interface over the open and save commands provided by the system.

Advantages:

1. Every application can use the features.
2. Standard interface.

Maybe Apps like Word will include more detailed information, such as template being used, other files being used in the document (pictures, etc.).

Doing everything by hand will get ya nowhere. An AppleScript interface would be a must.

'Newer' applications could sport a more sophisticated approach in structuring and relating data.

Additionally, an indexing service would run as a background app.

Any other suggestions?
I don't suffer from insanity, I enjoy every minute of it.
     
pelorus
Forum Regular
Join Date: Sep 1999
Location: Northern Ireland
Status: Offline
Reply With Quote
Apr 1, 2002, 08:14 PM
 
Originally posted by OreoCookie:
<STRONG>What would you want to see in the next-gen filesystem for OS X.

Here are two suggestions.

1. A journaling filesystem that repairs its damages by itself. No need for booting from a CD and use the Disk Utility.
What do you think about it?</STRONG>
I think you have no clue what a journaling file system is or what it is capable of. It's just a buzzword to you.

Ack!
     
OreoCookie  (op)
Moderator
Join Date: May 2001
Location: Hilbert space
Status: Offline
Reply With Quote
Apr 2, 2002, 04:11 AM
 
Ack, a journaling filesystem records every action in the log or journal prior to writing it. If the metadata in the journal is so-called 'committed' (which means it is valid), the metadata contained in the journal can be used. If not, the old data is the valid one. In that way, at least the old data is 'safe'.
When the computer crashes (maybe due to a power outage), the journal is read upon restart (or when manually invoked). The journal is compared to the data on the disk. If the metadata in the journal is committed, i. e. valid, but the file has not yet been updated, the computer does so. All 'not-committed' metadata is discarded, the old data is left intact.

Maybe I don't have in-depth knowledge about it, but I have an idea of how it works.

But this post wasn't intended to conduct an in-depth discussion, but rather a discussion of what an end-user should be able to do with it.

Rather than thinking of the implementation first, I wanted to think of the capabilities.
I don't suffer from insanity, I enjoy every minute of it.
     
sjk
Forum Regular
Join Date: Feb 2002
Location: Hawaii
Status: Offline
Reply With Quote
Apr 2, 2002, 10:09 PM
 
Originally posted by Millennium:
<STRONG>People seem to think that this "database-based filesystem" is some kind of magical panacea which will make all kinds of computing much easier in the future.
</STRONG>
I don't.
<STRONG>
Indeed, database-based filesystems do have a great deal of potential. But in order to use any of it, you have to have an interface to it; otherwise, it is useless.
</STRONG>
Very true.
     
Zarafa
Forum Regular
Join Date: Sep 2000
Location: Seattle, WA, USA
Status: Offline
Reply With Quote
Apr 3, 2002, 03:49 AM
 
For a good idea of some "modern filesystem" features beyond just database-like interfaces and journaling, there's an interesting read at http://www.namesys.com/v4/v4.html about Reiser4, the upcoming release of the ReiserFS.

Interested parties might want to do a search on "softupdates", "background fsck", "dirprefs", and "snapshots" to see where BSD filesystems are heading (often very divergent from the direction of Linuxy stuff like ReiserFS and ext3fs).
     
OreoCookie  (op)
Moderator
Join Date: May 2001
Location: Hilbert space
Status: Offline
Reply With Quote
Apr 3, 2002, 04:01 AM
 
Thanx for the link. In the German c't magazine (06/2002) There is a comparison between ext2, ext3, JFS, XFS, and ReiserFS (I probably forgot one). Very interesting.
I don't suffer from insanity, I enjoy every minute of it.
     
macnetic
Junior Member
Join Date: Oct 2000
Location: Vestnes, Norway
Status: Offline
Reply With Quote
Apr 3, 2002, 11:04 AM
 
Originally posted by OreoCookie:
<STRONG>I agree that such technology has to be implemented, otherwise it is worthless.

I could picture having an interface over the open and save commands provided by the system.

Advantages:

1. Every application can use the features.
2. Standard interface.

Maybe Apps like Word will include more detailed information, such as template being used, other files being used in the document (pictures, etc.).

Doing everything by hand will get ya nowhere. An AppleScript interface would be a must.

'Newer' applications could sport a more sophisticated approach in structuring and relating data.

Additionally, an indexing service would run as a background app.

Any other suggestions?</STRONG>
Just a comment... To enable stuff like searching for addresses in the heading of letters, youļæ½d have to have pretty strict use of templates. If you just type in an address, thereļæ½s no way for Word (or whatever) to know that itļæ½s an address, and that it should be stored as such.

This would become a problem for people like my ex boss, who doesnļæ½t really want to learn that thereļæ½s such a thing as a tab key, or text justification, and just uses spaces to eg. center a heading. And I know my boss is not alone in his ways...
     
clarkgoble
Mac Elite
Join Date: Mar 2001
Location: Provo, UT
Status: Offline
Reply With Quote
Apr 3, 2002, 04:59 PM
 
It would seem like the full database-like file system is very nice when the meta-tags are combined with aliases or symbolic links. Consider for instance a folder whose contents depend upon a query. Say, for instance, a folder called "Last Week's Mail." That uses query that searches all mail and using the mail file's meta-data puts your last weeks messages there. There are many other such things you could do.

The big issue ends up being meta-data. If you've read the book on BeOS' file system you can see how meta-data can become very powerful. (Very good book, by the way, and a must if you have to write even a simple file system like product) The question is whether Apple has had a change of heart regarding meta-data. I hope so since it really is very powerful.
     
OverclockedHomoSapien
Grizzled Veteran
Join Date: Mar 2001
Status: Offline
Reply With Quote
Apr 3, 2002, 05:52 PM
 
I'm not very knowledgeable about file systems, so this is probably not as good a solution as the others here, but...

What is wrong with using Sherlock to index your HD, and then searching for stuff with Sherlock?

Seriously, I don't understand why that isn't a good solution for most of you. Sherlock will search for both file names and file content, to me that seems like a very thorough search engine. And most searches I've done only take a few seconds.

What am I missing out on?
[FONT="book antiqua"]"If a nation expects to be ignorant and free, in a state of civilization, it expects what never was and never will be."
- Thomas Jefferson, 1816.[/FONT]
     
G Barnett
Grizzled Veteran
Join Date: Feb 2001
Location: Minnesota
Status: Offline
Reply With Quote
Apr 3, 2002, 06:08 PM
 
Biggest problem with Sherlock:

It only indexes the first 2000 words of files. Anything after that cannot be searched. If the key phrase you use starts at word 4500 in a file, you are SOL.


G Barnett
Life is like a clay pigeon -- sooner or later, someone is going to shoot you down and even if they miss you'll still wind up shattered and broken in the end.
     
OverclockedHomoSapien
Grizzled Veteran
Join Date: Mar 2001
Status: Offline
Reply With Quote
Apr 3, 2002, 06:25 PM
 
Ok, that's one limitation of Sherlock, although not a very big one. If a document is about MULES, then one would expect to find the word "Jackass" within the first few hundred words.

What other limitations does Sherlock have that warrant all this dreaming about new, bad-axxor file systems?

I'm curious, not trying to be dick or anything...
[FONT="book antiqua"]"If a nation expects to be ignorant and free, in a state of civilization, it expects what never was and never will be."
- Thomas Jefferson, 1816.[/FONT]
     
clarkgoble
Mac Elite
Join Date: Mar 2001
Location: Provo, UT
Status: Offline
Reply With Quote
Apr 4, 2002, 03:19 AM
 
The other issue with Sherlock is that it really doesn't use a lot of attributes (i.e. metadata) because right now the OSX Finder doesn't provide real metadata. Further Sherlock is an external program. It isn't part of your file system. You don't, for instance, see Sherlock results when you are using an Open File dialog box.

Consider, for instance, the kind of metadata you have with MP3 songs. You have things like song name, artist, album name. Imagine having one folder where you store all your music. Then you have other "made" folders for artist, and so forth. Yeah iTunes fakes a lot of this for you. But with it being done by the Finder instead of iTunes you can use any music program or even Unix commands to deal with your data. That's very powerful.

Further consider the email example I gave. Same sort of thing. Yeah you can do some of that with Mail or Entourage. But by putting it in with the Finder you first off have a more universal experience. Secondly you allow more applications to access the data. Finally you provide a much better way of managing your data - especially for power users or IT staff.

Having this kind of data managed by individual applications rather than the OS is a mistake (IMO). Right now you can fake a lot of organization and manipulation with Applescript, but by using the filesystem to manage metadata you really have a huge increase in power.
     
clarkgoble
Mac Elite
Join Date: Mar 2001
Location: Provo, UT
Status: Offline
Reply With Quote
Apr 4, 2002, 03:23 AM
 
One more thing - by having really good metadata support in the filesystem, Apple could develop a general control and revision system that would be killer. Imagine having a revision tree not only for your programs, but for your word documents, excel and so forth built into the OS. Further the metadata would give you, within the Finder, most of the features that Document Management systems have.

While I'm a little biased since I'm partially in the document management business, I think having a lot of those features in the Finder with a UI that makes the power available for "the rest of us" would be a dramatic increase in the power of the Macintosh. Further it is an increase in power that could largely be done by adopting a BeOS like filesystem and using OpenSource software tweaked by Apple.
     
OreoCookie  (op)
Moderator
Join Date: May 2001
Location: Hilbert space
Status: Offline
Reply With Quote
Apr 4, 2002, 04:42 AM
 
It would seem like the full database-like file system is very nice when the meta-tags are combined with aliases or symbolic links. Consider for instance a folder whose contents depend upon a query. Say, for instance, a folder called "Last Week's Mail." That uses query that searches all mail and using the mail file's meta-data puts your last weeks messages there. There are many other such things you could do.
BeOS could do that with queries alone. I have read about some people keeping their stuff in one folder and simply sorting it using queries.

What is wrong with using Sherlock to index your HD, and then searching for stuff with Sherlock?
Every time I start Sherlock, it starts indexing my HD, rendering its capabilities useless. I have an iBook, i. e. it usually doesn't run at night so that it can update its index.

While I'm a little biased since I'm partially in the document management business,
Sounds very interesting. You should have much more than a clue about the capabilities, a future filesystem could have.
I don't suffer from insanity, I enjoy every minute of it.
     
clarkgoble
Mac Elite
Join Date: Mar 2001
Location: Provo, UT
Status: Offline
Reply With Quote
Apr 4, 2002, 02:05 PM
 
Depending upon how you view directories, they are themselves a kind of metadata. Keeping all of your files in one directory, however, isn't very wise to me. It ends up being akin to writing a database with a field called "place" and having the same data in it for all records. Why would you do that? Folders/directories are a very effective way of organizing data.
     
OreoCookie  (op)
Moderator
Join Date: May 2001
Location: Hilbert space
Status: Offline
Reply With Quote
Apr 4, 2002, 02:31 PM
 
Didn't say I would.

I have read an article at The Vulture with an interview with the two persons responsible for the filesystem at Be.

One of them said that he used to do it that way. Personally I stick with Apple's folder layout.
I don't suffer from insanity, I enjoy every minute of it.
     
   
Thread Tools
 
Forum Links
Forum Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Top
Privacy Policy
All times are GMT -4. The time now is 05:06 AM.
All contents of these forums © 1995-2017 MacNN. All rights reserved.
Branding + Design: www.gesamtbild.com
vBulletin v.3.8.8 © 2000-2017, Jelsoft Enterprises Ltd.,