All of lore.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 18:18:14 +0100	[thread overview]
Message-ID: <20060213171814.GA22068@clipper.ens.fr> (raw)
In-Reply-To: <43F0AC38.9090409@cfl.rr.com>

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

Le quintidi 25 pluviôse, an CCXIV, Phillip Susi a écrit :
> Ahh, I see.  I've never seen anyone use it in conjunction with an si 
> prefix.  I also think that they use it in RFCs because at the time they 
> started writing them, bytes were not always 8 bits on all machines.  
> Today it is a pretty safe assumption that a byte is 8 bits, so most 
> people use the two terms interchangeably ;)

They continue using more octet than bytes even in recent RFCs. I have read I
do not remember where that the goal was to avoid byte/bit confusion.

I am sorry, I did not intend to start an off-topic subthread. I think I
should stick with kB/MB/GB unless I already used the full word earlier.

> I had that same thought a few weeks ago so I gave it a try.  I formatted 
> a partition with UDF, put some files on it, then booted windows to see 
> if it would take it.  It didn't :(

So bad... Perhaps it was asking too much...

> Hrm... interesting, I wonder how complete it is and what it's license 
> is?

The man page (<URL:
http://docs.sun.com/app/docs/doc/816-5166/6mbb1kq22?a=view > for Solaris 10,
I believe OpenSolaris is based on it) tells briefly that the checked
inconsistencies are (I quote):

- Blocks claimed by more than one file or the free list
- Blocks claimed by a file or the free list outside the range of the file system
- Incorrect link counts in file entries
- Incorrect directory sizes
- Bad file entry format
- Blocks not accounted for anywhere
- Directory checks, file pointing to unallocated file entry and absence of a
  parent directory entry
- Descriptor checks, more blocks for files than there are in the file system
- Bad free block list format
- Total free block count incorrect

I do not know UDF at all, so I can not tell if this is enough or not.

As for the licence, it is the one of OpenSolaris <URL:
http://www.opensolaris.org/os/licensing/opensolaris_license/ >, which is
free enough for the FSF to make efforts to have GPL3 compatible with it.


Regards,

-- 
  Nicolas George

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

      reply	other threads:[~2006-02-13 17:18 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
2006-02-13 15:56         ` Phillip Susi
2006-02-13 17:18           ` Nicolas George [this message]

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=20060213171814.GA22068@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.