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]
Date:	Fri, 3 Nov 2006 02:34:28 +0100 (CET)
From:	Mikulas Patocka <mikulas@...ax.karlin.mff.cuni.cz>
To:	Grzegorz Kulewski <kangur@...com.net>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: New filesystem for Linux

>> 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.
>
> Hmm, maybe. But I think I saw couple of such bad sectors that were only bad 
> because of power loss in the wild.
>
>
>> BTW. reiserfs and xfs depend on this feature too. ext3 is the only one that 
>> doesn't.
>
> Well, at least for XFS everybody tell that it should be used with UPS only if 
> you really care about your data. I think it has something to do with heavy 
> in-RAM caching this filesystem does.

System is allowed to cache anything unless sync/fsync is called. Someone 
told that XFS has some bugs that if crashed incorrectly, it can lose 
already synced data ... don't know. Plus it has that infamous feature (not 
a bug) that it commits size-increase but not data and you see zero-filed 
files.

> Anyway, it looks strange to list something very fragile and potentially not 
> existing in the requirements... :-)

Better to list it than quitly depend on it like ext2/fat/reiser/xfs/ 
(maybe jfs?) do.

> Could you explain where exactly do you depend on this requirement? And what 
> could happen if it is not true?

If you write a file in a directory and the sector is unwritable upon write 
& crash, you lose those few files near it. Just the similar way you would 
lose 4 files in inode table on ext2 in this case.

> Thanks,
>
> Grzegorz Kulewski
>
>
> PS. Do you have any benchmarks of your filesystem? Did you do any longer 
> automated tests to prove it is not going to loose data to easily?

I have, I may find them and post them. (but the university wants me to 
post them to some conference, so I should keep them secret :-/)

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ