public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nicolas George <nicolas.george@ens.fr>
To: Phillip Susi <psusi@cfl.rr.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: Filesystem for mobile hard drive
Date: Mon, 13 Feb 2006 11:35:12 +0100	[thread overview]
Message-ID: <20060213103512.GA5157@clipper.ens.fr> (raw)
In-Reply-To: <43EFEE57.7070009@cfl.rr.com>

[-- Attachment #1: Type: text/plain, Size: 2481 bytes --]

Le quartidi 24 pluviôse, an CCXIV, Phillip Susi a écrit :
> Ahh yes, the per file limit.  BTW, why are you saying "To" and "Go" when 
> you apparently mean "TB" and "GB"?

I use the french word octet instead of byte, because it is less error prone
(when you read "mb", does-it really mean megabit, or does it mean that the
author is lazy about capitalization?) and a little bit more precise. Tough I
actually am French, I did not start using a French word in English by
myself. I copy a practice of the IETF: the RFCs use octet more than byte.

> The fat data structures do not encourage fragmentation any more or less 
> than ext2/3.  NTFS is slightly better, more comparable to reiserfs than 
> ext2/3, but the difference is small.  What causes massive fragmentation 
> is how the driver chooses to allocate new blocks as you write to files. 
>  Microsoft has always used about the worst possible algorithm for doing 
> this you can imagine, which is why fragmentation has always been a big 
> problem on their OSes.  Linux is smarter and allocates blocks such that 
> fragmentation is kept to a minimum.

I believe you about that.

> I have not done any testing, but I know no reason why it would be worse 
> than fat.

That is a very good point. If windows can read UDF on hard drives and not
only DVD, UDF could probably supersede FAT completely.

Thank you for pointing me that direction.

>	    It does not do transaction logging, and there currently is no 
> fsck for it, so for safety reasons, it may not be such a good choice. 

I have a Solaris 9 near at hand, and I see a /lib/fs/udfs/fsck, and in the
source tarball of OpenSolaris, I find a directory
usr/src/cmd/fs.d/udfs/fsck/. It does not compile out of the box, but it may
be possible to port it with limited effort.

> I agree.  I think the VFS layer should process the uid/gid options.  By 
> default it should replace nobody with the specified id, and fat and ntfs 
> should just report all files as owned by nobody.  Then a new option 
> should be added to force the translation for all ids, not just nobody.

I agree with that (except maybe for the NTFS part, which I do not know; let
us just say "UID-less filesystems"). Maybe a full UID translation system
similar th the one in NFS could be useful, or a generic hook for modules,
but having basic UID overriding would be great.

Unfortunately, the VFS subsystem is something too complex for me at this
time.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 185 bytes --]

  parent reply	other threads:[~2006-02-13 10:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-12 15:03 Filesystem for mobile hard drive Nicolas George
2006-02-13  0:46 ` Phillip Susi
2006-02-13  1:07   ` Nicolas George
2006-02-13  2:26     ` Phillip Susi
2006-02-13  8:59       ` Jan Engelhardt
2006-02-13  9:23       ` Kalin KOZHUHAROV
2006-02-13 16:07         ` Phillip Susi
2006-02-13 10:35       ` Nicolas George [this message]
2006-02-13 15:56         ` Phillip Susi
2006-02-13 17:18           ` Nicolas George

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060213103512.GA5157@clipper.ens.fr \
    --to=nicolas.george@ens.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=psusi@cfl.rr.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox