Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Heavy SSD Writes from Firefox

servethehome.com

Post reply on HN
Print view View original

351–360 of 361 posts

Re: Heavy SSD Writes from Firefox

#351

Post by acqq »

alphapapa wrote: post #345
acqq wrote: post #325

Earlier quoted context omitted.

So "somebody" was me at the end, I've rolled up my sleeves and extracted the damn pictures: in my 1.7 MB session file approximately 1 MB were the base64 encodings of exactly 57 jpeg pictures that were all the result of the Google image search (probably of the single search). There were additionally a few pngs, representing "facebook, twitter, gplus" images and one "question mark sign" gif too.

Thank you for doing that. This explains much. For a while now I have been running a cronjob to commit my profile's sessionstore-backups directory to a git repo every 5 minutes. This is because, occasionally, when Firefox starts, it will load tabs in some kind of limbo state where the page is blank and the title is displayed in the tab--but if I refresh the page, it immediately goes to about:blank, and the original ta…

If I understood the intention of the programmers, they simply want to store "everything that can imitate to the server the continuation of the current session" even after the new start of the Firefox (like the restart never happened). The images were sent by Google, but probably remain in the DOM tree which is then written as the "session data" or something like that.

Like you, I also observed that exactly the people who depend on the tabs to "remain" after the restart are those who are hit by the bugs in the "restoration" and as I've said, I believe the users would more prefer to have "stable" tabs and URLs than the "fully restored sessions in the tabs" when all the tabs fully randomly (for them) disappear. Maybe saving just the tabs and URLs separately from "everything session" would be a good step to the robustness (since it would be much less data and much less chance to get corrupted) and then maybe, pretty please, an option "don't save session data" can be in the about:config too)?

Once there's decision to store just the URLs of the tabs as the separate file, the file can even be organized in a way that just the URL that is changed gets rewritten, therefore making the "complete corruption" of the file impossible and also removing the necessity for Firefox to keep N older versions of the big files (which then eventually still don't help the user like you).

Re: Heavy SSD Writes from Firefox

#353

Post by rovr138 »

wolf550e wrote: post #248
avar wrote: post #235

Earlier quoted context omitted.

Only if the sync is the equivalent of: rsync [...] /dev/shm/.browser ~/.browser Instead of: rsync [...] /dev/shm/.browser ~/.browser.new && ln -sf ~/.browser.new ~/browser Or some such equivalent, i.e. doing the full sync and then atomically juggling a symlink around.

that creates many more writes to the ssd.

He should have used --link-dest= on his rsync.

    PREVIOUS_BACKUP=$(cat ./prev_backup)
    NEW_BACKUP=$(date +%F_%T)

    rsync --link-dest=$PREVIOUS_BACKUP /path/source /path/dest/$NEW_BACKUP

    echo $NEW_BACKUP > ./prev_backup
This will copy /path/source to /path/dest/$NEW_BACKUP (which is a time stamped folder). But it will take into account the previous backup. If a file hasn't changed, it will create a hard link. If it changed, it will then copy the whole file.

And that's it.

Since it's the name is a time stamp. When you need to restore, just read ./prev_backup or just list the directory content, sort it and read the last entry.

Re: Heavy SSD Writes from Firefox

#354

Post by alphapapa »

acqq wrote: post #351
alphapapa wrote: post #345

Earlier quoted context omitted.

Thank you for doing that. This explains much. For a while now I have been running a cronjob to commit my profile's sessionstore-backups directory to a git repo every 5 minutes. This is because, occasionally, when Firefox starts, it will load tabs in some kind of limbo state where the page is blank and the title is displayed in the tab--but if I refresh the page, it immediately goes to about:blank, and the original ta…

If I understood the intention of the programmers, they simply want to store "everything that can imitate to the server the continuation of the current session" even after the new start of the Firefox (like the restart never happened). The images were sent by Google, but probably remain in the DOM tree which is then written as the "session data" or something like that. Like you, I also observed that exactly the people…

> Maybe saving just the tabs and URLs separately from "everything session" would be a good step to the robustness (since it would be much less data and much less chance to get corrupted)

Yes, that would be very, very useful. I can get by if the tab's scroll position and favicon and DOM-embedded images--and even formdata--are lost. But if the tab itself is lost, and it was a page I needed to do something with, I may never even realize it is gone...

Re: Heavy SSD Writes from Firefox

#355

Post by cwillu »

alphapapa wrote: post #348
Yoric wrote: post #156

Earlier quoted context omitted.

I haven't worked on Session Restore in some time. But from the top of my head, it would be as follows. On the back-end, I believe that Session Restore should be backed by a database, with each tab updated independently, rather than a big bunch of JSON data. The rationale being that: - it's performance-critical; - it's safety-critical; - we have users with 300+ Mb of data in their Session Restore and JSON isn't meant…

Using a SQLite database for Session Restore seems to make sense. However, it would make it even more difficult to get data out of it when necessary. As ugly as a mess of JSON is, at least it's text, and I don't have to write a SQL query to grep for URLs. Why not just use the filesystem? Imagine a layout like this: + profilename.default |--+ sessionrestore |--+ |--+ window1 | |--+ tab1 | | |--- cookies | | |--- formda…

Not cross platform, without a tonne of extra work that, surprise surprise, things like sqlite already take care of. Overengineering is ignoring the off-the-shelf part that solves your problem because you "know" you could do it better yourself, in a simpler fashion.

It's a non-issue anyways, I have yet to see anyone show any actual evidence of an ssd dying prematurely or suffering degraded performance from this behaviour.

Re: Heavy SSD Writes from Firefox

#356

Post by arpa »

cwillu wrote: post #355
alphapapa wrote: post #348

Earlier quoted context omitted.

Using a SQLite database for Session Restore seems to make sense. However, it would make it even more difficult to get data out of it when necessary. As ugly as a mess of JSON is, at least it's text, and I don't have to write a SQL query to grep for URLs. Why not just use the filesystem? Imagine a layout like this: + profilename.default |--+ sessionrestore |--+ |--+ window1 | |--+ tab1 | | |--- cookies | | |--- formda…

Not cross platform, without a tonne of extra work that, surprise surprise, things like sqlite already take care of. Overengineering is ignoring the off-the-shelf part that solves your problem because you "know" you could do it better yourself, in a simpler fashion. It's a non-issue anyways, I have yet to see anyone show any actual evidence of an ssd dying prematurely or suffering degraded performance from this behavi…

what operating system does not have filesystem support? :(

Re: Heavy SSD Writes from Firefox

#357

Post by retro64 »

EpicEng wrote: post #301
Retra wrote: post #294

Earlier quoted context omitted.

>The reality is that even with fairly heavy use, most of them will far outlive the computers they're in. I'm not sure what the lifetime of a computer is. In my family, we are still occasionally running machines from circa 1995. They work fine. When should I stop using my MacBook? The only reason I'd stop is if it died in a way that can't be cheaply fixed.

>I'm not sure what the lifetime of a computer is. In my family, we are still occasionally running machines from circa 1995. Pretty sure it's not 21 years, c'mon...

1995 is a stretch for anything modern but I have kids playing Minecraft on Pentium 4’s (with decent graphic cards though - that is the critical part). These boxes would have been new around 2003 or so.

Re: Heavy SSD Writes from Firefox

#358

Post by Senji »

chime wrote: post #244
cpncrunch wrote: post #236

Earlier quoted context omitted.

Agreed. If my computer crashes (once in a blue moon) I would be happy for it to just open the urls again. I don't care whatsoever about it keeping the current state of every tab. If any users do care about that, it should be optional (perhaps a tickbox in the preferences window).

My FF has crashed many times on OS X and while it does restore the URLs, it has never restored the state. I know it because sometimes I am in the middle of writing a comment and it crashes. On recovery, the comment is gone.

Get Lazarus

https://addons.mozilla.org/en-US/firefox/addon/lazarus-form-...

Re: Heavy SSD Writes from Firefox

#359

Post by Senji »

alphapapa wrote: post #348
Yoric wrote: post #156

Earlier quoted context omitted.

I haven't worked on Session Restore in some time. But from the top of my head, it would be as follows. On the back-end, I believe that Session Restore should be backed by a database, with each tab updated independently, rather than a big bunch of JSON data. The rationale being that: - it's performance-critical; - it's safety-critical; - we have users with 300+ Mb of data in their Session Restore and JSON isn't meant…

Using a SQLite database for Session Restore seems to make sense. However, it would make it even more difficult to get data out of it when necessary. As ugly as a mess of JSON is, at least it's text, and I don't have to write a SQL query to grep for URLs. Why not just use the filesystem? Imagine a layout like this: + profilename.default |--+ sessionrestore |--+ |--+ window1 | |--+ tab1 | | |--- cookies | | |--- formda…

Have you considered minimum FS Cluser/Blocksize? Older versions of IE used to write cookies in plaintext files. So now you're wasting 4096 bytes for a few bytes of storage.
Post reply on HN