On Mon, Jun 03, 2013 at 01:56:10PM +0200, Papp Tamas wrote: > On 05/30/2013 02:55 PM, Stefan Behrens wrote: > > > >On Thu, 30 May 2013 08:32:35 -0400, Josef Bacik wrote: > >>On Thu, May 30, 2013 at 05:17:06AM -0600, Papp Tamas wrote: > >>>hi All, > >>> > >>>I'm new on the list. > >>> > >>>System: > >>>Distributor ID: Ubuntu > >>>Description: Ubuntu 13.04 > >>>Release: 13.04 > >>>Codename: raring > >>> > >>>Linux ctu 3.8.0-19-generic #30-Ubuntu SMP Wed May 1 16:35:23 UTC 2013 > >>>x86_64 x86_64 x86_64 GNU/Linux > >>> > >>>The symptom is the same with Saucy 3.9 kernel. > >> > >>Can you try btrfs-next > >> > >>git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git > >> > >>if it's still not fixed please file a bug at bugzilla.kernel.org and make > >>sure > >>the component is set to btrfs. Thanks, > > > >Papp is using an Intel X18-M/X25-M/X25-V G2 SSD. At least with an Intel > >X25 SSD that identifies itself with "INTEL SSDSA2M080" and on one with > >the ID "INTEL SSDSA2M040", I've tested whether they honor the flush > >request. And these two SSDs don't do so, they ignore it. If you cut the > >power after a flush request completes, the data that was written before > >the flush request is gone, the write cache was _not_ flushed. > > > >You can only disable the write cache during/after every boot "hdparm -W > >0 /dev/sd..." (which reduces the SSDs write speed to about 4 MB/s), or > >avoid such SSDs, or prepare to restore from backup occasionally. > > Basically it means it's not safe to use this SSD?
Correct. > I used it for 2 years with ext4 without any issue, before I switched > to btrfs (on the root partition). In the meantime btrfs also was > quite stable on my /data partition. > > After I reinstalled thr system with btrfs, this issue happened two times. > But anyway, I thought cow should be able to handle these kind of issues by > design. Am I wrong? CoW writes out everything that's going to be changed first, and finally writes one piece of data which points to the new version of the data. *Provided* you can guarantee that the final piece of data (the superblock) gets written only after everything else has made it to permanent storage, then everything is good. However, most hardware (and most operating systems) reorder the data which is being sent to the disk, for performance reasons. This is fine, as long as you can enforce the dependency in some way -- this is what barriers/flushes do: they say "ensure that all of this is fully written out to real permanent storage before you try to write the superblock". If the hardware ignores flushes or barriers, there's no mechanism for ensuring that the data is fully consistent, because you may find that the superblock gets reordered to be written before some of the other writes to the device. If that happens and then the power gets cut before the rest of the data can be written, you have a corrupt filesystem. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- In theory, theory and practice are the same. In --- practice, they're different.
signature.asc
Description: Digital signature
