Le 21/01/2012 10:23, C a écrit :

On Sat, Jan 21, 2012 at 09:36, jdd wrote:

...

I wonder if it's a good idea to use a small ssd drive (now afordable) for openSUSE system on a desktop, and with what config. 20Gb is much more than necessary for the system.

I suppose it's better to move variable parts to standard HDD (/var, /tmp, /etc??)

any experience?

There was a long discussion on this a few weeks ago, and the conclusion is... there is no conclusion.

thanks for you long and informative answer jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 1/22/2012 8:52 PM, Adam Tauno Williams wrote:

Use btrfs and you can be comfortable you are using SSD-specific stuff even though it probably doesn't matter in any meaningful way.

Use btrfs and you can be comfortable you will lose everything once in a while. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 1/23/2012 4:03 PM, C wrote:

On Mon, Jan 23, 2012 at 21:28, Brian K. White wrote:

...

On 1/22/2012 8:52 PM, Adam Tauno Williams wrote:

...

Use btrfs and you can be comfortable you are using SSD-specific stuff even though it probably doesn't matter in any meaningful way.

Use btrfs and you can be comfortable you will lose everything once in a while.

I've been using btrfs since 12.1 came out.. .no problems. Well not 100% true. I did have to run the btrfs repair tool once... and after looking into what went wrong etc, I came to the conclusion it was my fault for poking around a little too much. After the repair, I left it alone... and no problems at all.

C.

Wow, that long? one pc since 12.1 came out? And only one problem that you were luck enough to recover from? In all those weeks and weeks of testing by all those 1 machines performing I'm guessing no exhaustive stress-test? You practically make my point merely by how little you counter it, if that were possible. A filesystem needs a lot more testing and proof of stability before you can recommend it to unsuspecting people to actually use. Making recommendations like this implies a certain amount of responsibility. Also, is https://btrfs.wiki.kernel.org/ wrong? "Note that Btrfs does not yet have a fsck tool that can fix errors." -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 1/23/2012 2:24 PM, C wrote:

On top of that i did NOT recommend btrfs... I simply stated that I've been running it on an unspecified number of machines and have had only one issue.

The single issue I had was very easily repaired using the information stated here (top FAQ regarding kernel oops): https://btrfs.wiki.kernel.org/articles/p/r/o/Problem_FAQ_68af.html

Anyway, I don't want to have an argument here. This is my only reply on this thread.

C.

And still you refuse to specify? Any failure THIS SOON after you started using it is pretty much an indication of instability regardless how much "poking" you did. That being said, I'd wanted to try it out, tried it in a Virtual Machine (ubuntu) and had no problems. But my need of that VM vanished, and, because it was a virtual machine, it couldn't be considered a real world test anyway. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, 2012-01-23 at 23:51 +0100, jdd wrote:

Le 23/01/2012 23:24, C a écrit :

...

Anyway, I don't want to have an argument here. This is my only reply on this thread.

anyway, I don't see why btrfs should be better on ssd, or is there something I missed?

One of the features of btrfs is (if i remember correctly) that when you change a file, the updated data is written on other disk-blocks, the previous ones are left unchanged, but are linked out. (copy-on-write) That should have two results: a) it is supposedly faster, b) the number of times written to the _same_ block is vastly reduced: the whole disk is used, until there are no longer "virgin" blocks anymore. Only then a disk block is re-written. And as, with sdd's, the number of write-actions on any block is limited, reducing the number of writing to the same block, will have positive influence on the lifespan of your sdd. However, this in unrelated to all other zillion aspects of each file system. afaict each of them has it's own pro's and con's. No holy grail, no final answer (besides 42). hw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

jdd wrote:

Le 24/01/2012 10:54, Hans Witvliet a écrit :

...

And as, with sdd's, the number of write-actions on any block is limited, reducing the number of writing to the same block, will have positive influence on the lifespan of your sdd.

is not the ssd subsystem supposed to do this in the more effective way?

Btrfs doesn't do this because of ssd support. It does it so that old versions of files can be recovered easily. And recovered is the wrong term. It formally maintains and makes available those older versions. Ntfs has done this since windows 2003 came out. MS calls the old versions shadow copies. Btrfs calls them snapshots I believe. Yast has a "snapper" module in os 12.1 to manage the snapshots. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Monday 23 Jan 2012 16:44:37 Brian K. White wrote:

Also, is https://btrfs.wiki.kernel.org/ wrong? "Note that Btrfs does not yet have a fsck tool that can fix errors."

And so what if it doesn't? ZFS Doesnt have one and is considered stable (corruption of ZFS pools still hapens though). XFS didn't used to have one but was "stable" and in use long before an fsck tool was developed for it. Oh and all those expensive enterprisey NetApp systems? Yep there was no fsck for WAFL either at first and that didn't stop it's widespread use. I'm not making any claims about btrfs fitness for use, but not having an fsck tool is *not* an indication of it's level of fitness for use. If the arguement is "don't use it because if something goes wrong you're screwed" then that arguement holds the same weight and truth for ZFS. And yes that arguement *is* valid for ZFS because, corrupt zfs pools *do* happen. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org