linux-kernel - Re: New filesystem for Linux

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <454B3EB2.3010600@emc.com>
Date:	Fri, 03 Nov 2006 08:05:54 -0500
From:	Ric Wheeler <ric@....com>
To:	Mikulas Patocka <mikulas@...ax.karlin.mff.cuni.cz>
CC:	Grzegorz Kulewski <kangur@...com.net>, linux-kernel@...r.kernel.org
Subject: Re: New filesystem for Linux

Mikulas Patocka wrote:

>> Hi,
>>
>> On Thu, 2 Nov 2006, Mikulas Patocka wrote:
>>
>>> As my PhD thesis, I am designing and writing a filesystem, and it's 
>>> now in a state that it can be released. You can download it from 
>>> http://artax.karlin.mff.cuni.cz/~mikulas/spadfs/
>>
>>
>> "Disk that can atomically write one sector (512 bytes) so that the 
>> sector
>> contains either old or new content in case of crash."
>>
>> Well, maybe I am completly wrong but as far as I understand no disk 
>> currently will provide such requirement. Disks can have (after halted 
>> write):
>> - old data,
>> - new data,
>> - nothing (unreadable sector - result of not full write and disk 
>> internal checksum failute for that sector, happens especially often 
>> if you have frequent power outages).
>>
>> And possibly some broken drives may also return you something that 
>> they think is good data but really is not (shouldn't happen since 
>> both disks and cables should be protected by checksums, but hey... 
>> you can never be absolutely sure especially on very big storages).
>>
>> So... isn't this making your filesystem a little flawed in design?
>
>
> There was discussion about it here some times ago, and I think the 
> result was that the IDE bus is reset prior to capacitors discharge and 
> total loss of power and disk has enough time to finish a sector --- 
> but if you have crap power supply (doesn't signal power loss), crap 
> motherboard (doesn't reset bus) or crap disk (doesn't respond to 
> reset), it can fail.

These are two examples of very different classes of storage devices - if 
you use a high end array (like EMC Clariion/Symm, IBM Shark, Hitachi, 
NetApp Block, etc) once the target device acknowledges the write 
transaction, you have a hard promise that the data is going to persist 
after a power outage, etc.

If you are using a a commodity disk, then you really have to worry about 
how the drive's write cache will handle your IO.  These disks will ack 
the write once they have stored the write request in their volatile 
memory which can be lost on power outages.

That is a reasonable setting for most end users (high performance, few 
power outages and some risk of data loss), but when data integrity is a 
hard requirement, people typically run with the write cache disabled.

The "write barrier" support that is in reiserfs, ext3 and xfs all 
provide something that is somewhere in the middle - good performance and 
cache flushes injected on transaction commits or application level 
fsync() commands.

I would not depend on the IDE bus reset or draining capacitors to safely 
destage data - in fact, I know that it will routinely fail when we test 
the write barrier on/off over power outages.

Modern S-ATA/ATA drives have 16MB or more of data in write cache and 
there is a lot of data to destage in those last few ms ;-)

>
> BTW. reiserfs and xfs depend on this feature too. ext3 is the only one 
> that doesn't.
>
> Mikulas
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/