[plug] Data Loss with Ext4, SSD & a Power Outage

[ıuoʎ]

That sounds really weird.
I've been working with an SSD for a while now and never had any of this
issues (but I'm using it on a laptop so never had any power faults).
I don't know a lot about this but 10 mins sound like ages to me surely
enough for the SSD to permanently save most of the changes


When you checked the file did you do it from PHP Storm or did you just
checked it with a regular text editor ?
PHP Storm does a lot of version management for your changes it might be
that it decided to restore your file in the wrong state.
what the PHP Storm history shows for the file ?

I wouldn't try to recreate this scenario on purpose, doesn't sound very
healthy for the hardware in general.


On Tue, Sep 2, 2014 at 1:31 PM, Tim <weirdit at gmail.com> wrote:

> Just hoping someone here can shed light on this one.
>
> My /home is mounted on a SSD, and I was working on a new file the other
> day (source code), using PHPStorm as my editor. (I'm normally a Vim user,
> but having been trialling it for some of it's source code refactoring
> tools).
> I had saved the file a number of times, and know the saves had been
> "working" as I'd been loading the PHP Class via the webserver, testing the
> components I was working on.
> Then the power "failed" (a child bumped the powerpoint), and when I
> restarted the computer, the file I'd been working on, and the workspace.xml
> file PHPStorm uses to keep track of open files, were both empty. They both
> existed, but it was if they were truncated.
> Given I'd only lost a small amount of work (it was a new class file), I
> started it again. 10 minutes later, the same happened, a child bumped the
> power cable, upon restart the same 2 files were again "truncated".
> This time however, I'd gotten a bit more work done, and know I'd hit save
> many times while I'd worked, and checked both my Dropbox and my local
> script rdiff-backup script, and sure enough the file contents were in both
> locations. After the restart, Dropbox had of course "truncated" the file on
> the server to match my client, but thanks to revisions I was able to
> rollback to my last saved revision, and only lost 1 line, the line I was
> typing before the power outage.
>
> So given that both Dropbox and my rdiff-backup script had the file
> contents, why was the file being truncated on the SSD, the origin for the
> file?
>
> I can only assume that a file write cache was to blame, but my reading of
> 'man mount' suggests that the commit interval is 5 seconds. And that's
> supposed to be metadata and data. I checked with a few mount commands and
> verified that if you set the commit interval to the default of 5, it
> doesn't show in the mount options, changing it from the default you then
> see it in the mount options.
>
> $ cat /proc/mounts |grep home
> /dev/sdg2 /home ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
>
> The destination for the rdiff-backup script is local, but on a spinning
> disk HDD, and it's copy was correct. It's mount options are:
> /dev/sde3 /mnt/data1 ext4 rw,relatime,data=ordered 0 0
>
> The only other thing I can think of, is that the PHPStorm editor doesn't
> send a Sync command, allowing those writes to sit in cache, while
> rdiff-backup sends a Sync. But if that's the case, then the commit interval
> that mount talks about isn't accurate, and my googling pointing me to the
> commit interval is also wrong.
>
> Any suggestions? I'm willing to recreate the scenario to try and work out
> why it's happening.
>
> Tim
>
> --
> Timothy White - Somewhere in Australia
>
>
> _______________________________________________
> PLUG discussion list: plug at plug.org.au
> http://lists.plug.org.au/mailman/listinfo/plug
> Committee e-mail: committee at plug.org.au
> PLUG Membership: http://www.plug.org.au/membership
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plug.org.au/pipermail/plug/attachments/20140907/b365f7de/attachment.html>