[Openmcl-devel] ccl on ext4

[Gary Byers]

I didn't understand the original question; I have no idea what it means
to "work correctly" with a filesystem (and even less of an idea of what
it would mean to "certify" that.)

The Wikipedia article that Ron cites notes that a delayed allocation
policy (as offered by ext4, ZFS, HFS+, ...) can increase the chance
that on-disk data will be inconsistent in the event of a power loss
(or that the inconsistencies will be more severe.)  I can't think of
a filesystem that really guarantees disk consistency after #_write;
there are typically all kinds of buffering and caching mechanisms
involved.  (If disk consistency is important, you have to call #_fsync
to defeat those mechanisms; FINISH-OUTPUT calls #_fsync in CCL.)

The differences between filesystems' behavior (especially differences
that relate to when sectors/allocation units/extents are allocated)
can be significant (especially in cases involving disk consistency)
and in some contexts may be interesting, but it's not  clear what any
of this has to do with CCL; I can't think of any code in CCL that
tries to determine filesystem type or attributes and certainly can't
think of any case where it tries to override or adapt to things like
caching and allocation behavior.  (Those sorts of things are really
the filesystem's job and not that of userspace code.)

You certainly might want to say "for this file (or as a matter of
general policy), disk consistency is more important than minimizing
fragmentation or optimizing write performance."  When that's true,
it's true regardless of the underlying filesystem's default policies.
FINISH-OUTPUT gives you some control over this, and CCL could give
you more control than it does over application-level buffering.

The only filesystem attribute that I can think of that's arguably
CCL's business is case-sensitivity.  Whether or not this information's
reliably available or not tends to be platform-dependent and it's
not clear that it's really practical to make things like EQUAL
query that information (even though doing so could yield a more
correct answer.)  That whole issue may be interesting, but it's
not clear that it has much to do with the original question either.

The person who asked that question seemed to be satisfied by Matt's
answer, so the fact that I still can't guess what the question means
is probably not of general interest.





On Mon, 11 Jul 2011, Ron Garret wrote:

> http://en.wikipedia.org/wiki/Ext4#Delayed_allocation_and_potential_data_loss
>
> On Jul 11, 2011, at 5:13 PM, Bit Twiddler wrote:
>
>> That's kind of what I thought. In a thousand years from
>> now, when we have our first encounter with an alien
>> civilzation, they are going to have 2 Big Questions
>> for us:
>>
>> 1. How come you are using a non-orthogonal instruction set?
>>
>> 2. How come you are still using ext3?
>>
>>
>> On Mon, Jul 11, 2011 at 4:20 PM, R. Matthew Emerson <rme at clozure.com> wrote:
>>
>> On Jul 11, 2011, at 4:47 PM, Bit Twiddler wrote:
>>
>>> I know that this has probably been discussed before,
>>> but does anybody know whether ccl has been certified
>>> by its maintainers to work properly on the ext4 file system?
>>
>> I would say that CCL is certified to take up space on your disk.
>> Anything more than that...well, not so much.
>>
>> I think CCL is reasonably good about calling fsync before streams
>> wrapped around file descriptors are closed, but as far as
>> I know, nobody has tried to comb through the file i/o code
>> with the specific thought "is this going to be robust in
>> the face of power loss and delayed block allocation" in mind.
>>
>>
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>