Weekly snapshot server

[Hydra]

I've put up a weekly snapshot server:

203.26.94.236:6969

The world will get wiped when a new weekly is installed, this is just so we can play with new features.

No bukkit, no plugins.

http://www.mojang.com/2012/08/the-weekl ... ot-12w32a/

[hoqhuuep]

Ooh, nice! Thank you sir! =D

[Hydra]

FWIW, I am running the main world for this server inside a ramdisk, so it is super fast.

It seems to be quite effective I dare say a SSD would be almost as good.

[brimlad]

thanks Hydra, be good to try the snapshots.

cheers

[MacrossFiru]

FWIW, I am running the main world for this server inside a ramdisk, so it is super fast.

It seems to be quite effective I dare say a SSD would be almost as good.

Except the excessive dense locality of IO would probably shorten it's life to about a month.

[monotonehell]

FWIW, I am running the main world for this server inside a ramdisk, so it is super fast.

It seems to be quite effective I dare say a SSD would be almost as good.

Except the excessive dense locality of IO would probably shorten it's life to about a month.

This is a misconception. I've been running a large Minecraft server on an SSD in a datacentre for over a year now. Works really well.

[Hydra]

Except the excessive dense locality of IO would probably shorten it's life to about a month.

That is why I do backups

[monotonehell]

Except the excessive dense locality of IO would probably shorten it's life to about a month.

That is why I do backups

Hehe, yeah those are a good idea regardless of the kind of drive.

[MacrossFiru]

This is a misconception. I've been running a large Minecraft server on an SSD in a datacentre for over a year now. Works really well.

it was hyperbole

with wear leveling and TRIM, SSDs will be more resistent to overall wear failure and write amplification and each block will tolerate about a million erase cycles, so n*(1*10^6)~ write operations on the volume as a total is possible, where N is the number of eraseable SSD blocks (not file system pages), it's a guaranteed eventuality but it's still true at some level that repedative write behavior especially to static block addresses pose a longevity issue.

In short, YAY and stuff.

[monotonehell]

This is a misconception. I've been running a large Minecraft server on an SSD in a datacentre for over a year now. Works really well.

it was hyperbole

with wear leveling and TRIM, SSDs will be more resistent to overall wear failure and write amplification and each block will tolerate about a million erase cycles, so n*(1*10^6)~ write operations on the volume as a total is possible, where N is the number of eraseable SSD blocks (not file system pages), it's a guaranteed eventuality but it's still true at some level that repedative write behavior especially to static block addresses pose a longevity issue.

In short, YAY and stuff.

After your first post I went to look at how the data centre had installed the SSD. It is ext3, without noatime, and without discard. *sigh* I guess it will fail sooner rather than later. I don't like the idea of having to reformat it ext4 with the appropriate options at this point in time. Maybe I'll just get a new box lol.

[MacrossFiru]

hahaha nice clip, I wouldn't worry about FS book keeping structure TOO much if ATime is disabled that's a huge amount of writes culled, also if your drive supports and is operating TRIM and it has a decent wear leveling algorithm it's probably not a major issue what FS you use, you COULD find out what the drive block size is (the higher the density the larger the blocks), unlike HDDs you typically wont get blocks less than 4KiB so you could in the future optimise further by aligning your fs block size to the SSD erase block size although that means small files would be less efficiently stored. it's a bit of a balancing act really, ultimatley if it aint broke dont fix it

[Hydra]

Hmm I'm not sure you can use discard with ext3. I believe if you mount as ext3 with discard the partition will be read only.

[MacrossFiru]

not sure myself afaik discard just tags blocks that are freed so the SSD can wipe them I don't see why it couldn't be implemented, who knows, EXT3 is now "old"

[monotonehell]

Yup no discard (aka trim?) with ext3 hence my *sigh*

[MacrossFiru]

Discard/Trim doesn't improve wear leveling (in some cases if the SSD firmware sucks it can cause wear), it improves overall write performance on a volume by tagging blocks for erasure, the SSD is able to erase marked blocks while they're not in use (provided the pages freed is equal to or greater than the erasable block size) so when the OS goes to write to them again there's no need to Read-Erase-Write because the block is already erased, EXT3 and EXT4 still have a banded volume structure so things like inodes and static bitmaps still pose an issue, BTRFS looks like it will be better suited in the long term its a good balance for both SSD and rotating media :3