<aldeka>
Some of their recruiters seem to think that interviews for some kinds of developer positions will be skills-based, not algorithms and data structures.
<aldeka>
(and then you arrive and ha ha no)
<aldeka>
It is unimaginable to me that setting up incorrect expectations would in any universe result in better hiring outcome data. :P
<kentonv>
aldeka: The recruiters literally have no idea what the interviewers are going to ask.
<kentonv>
it's entirely up to each interviewer
<aldeka>
Clearly.
natea has joined #sandstorm
bb010g has joined #sandstorm
<eldios>
guys, let's assume that I want to backup sandstorm and restore it on another system.
<eldios>
would it be enough to move /opt/sandstorm on the new system and that's it?
<eldios>
it should be self-contained right? so that should be enough (other than boot init scripts and bin symlinking)
<jeffmendoza_>
eldios: It would probably be better to save all your grains and restore them on the new server. Make sure to save your sandcats private key from /opt/sandstorm/var/sandcats if you want to save your dns name
<eldios>
jeffmendoza_: let me check how to do that
<eldios>
oh wait
<eldios>
wait wait wait
<eldios>
do you mean by browsing each of those and then saving them from the browser?
<jeffmendoza_>
yes
<eldios>
mmm
<eldios>
that would be quite a sub-optimal backup solution
<jeffmendoza_>
yeah, I don't know what the future plans are
<jeffmendoza_>
automated backups, etc.
<eldios>
thanks anyway jeffmendoza_
<ocdtrekkie>
I very much want a "download all my things" button and an "upload lots of things" button.
jeffmendoza_ has quit [Remote host closed the connection]
<zarvox>
snapshotting /opt/sandstorm (and everything under it) should give you a point-in-time backup of all sandstorm data on that particular machine, with the exception of init scripts and linking to bin.
<zarvox>
It may be as little as /opt/sandstorm/var and /opt/sandstorm/sandstorm.conf, actually, since the rest of the bundle can be refetched/upgraded
<eldios>
zarvox: do you mean atomic snapshotting (like LVM/btrfs shapnots) or just copy everything out at once (rsync, tar, ecc..)?
natea has quit [Quit: natea]
<zarvox>
Well, if sandstorm is stopped, then you could copy everything out at once.
<eldios>
makes sesne
<zarvox>
Otherwise, mongo's DB could get corrupted.
<eldios>
mm
<eldios>
okay
<eldios>
will go down that route and see
<eldios>
thanks for your confirms
natea has joined #sandstorm
<kentonv>
anyone know much about ext4 journaling behavior?
<kentonv>
XgF maybe?
<eldios>
kentonv: specifically what?
<kentonv>
so I have an ext4fs with data=ordered (the default)
<kentonv>
I'm appending to a file
<kentonv>
I cut the connection to the block device (atomically, so all writes before time X go through, and all after do not)
<kentonv>
on remount, I find the file has a bunch of zeros at the end
<kentonv>
I thought that shouldn't happen, since the description of data=ordered says data will be flushed before metadata changes
<kentonv>
and size is metadata
<kentonv>
so I want to know if my assumption is right or wrong, which determines what I do next
<eldios>
when you say "I cut the connection to the block device" is that by powering it down since it's a physical device?
<kentonv>
no, it's not a physical device
<kentonv>
it's actually NBD
<kentonv>
both machines remain running, I just cut the network connection.
<eldios>
have you tried doing that same operation with the "sync" option enabled ?
<kentonv>
sync option enabled where?
<eldios>
on the ext4 filesystem mount options
<XgF>
kentonv: I don't know about EXT4 specifically, but on most FSes there is an implicit barrier between resize and actual write
<kentonv>
XgF: hmm, you mean resize happens first, followed by write?
<eldios>
but still, I'd try with the sync behavior first
<eldios>
eg: mount -o sync,$other_options /dev/your_dev /mountpoint
<XgF>
kentonv: Yes
<zarvox>
sync means "skip the page cache," right?
<eldios>
pragmatically speaking, yes
<kentonv>
XgF: Hmm, that would seem to explain it then. Seems to go against the description of data=ordered, though? Are trailing zeros a known common problem after power loss?
<kentonv>
eldios: I don't think barriers are the issue. In my setup, writes could not possibly be applied out-of-order (unless I have a bug).
<eldios>
kentonv: that's why I was thinking of the cache as the first test.
<XgF>
kentonv: I suspect that for file system consistency, the FS needs to update the size of the file before it actually writes the data. I suspect this is other metadata
<XgF>
You should probably either avoid enlarging the file or write verfiable (i.e. at least CRCd) blocks to your jorunal
<XgF>
One possibility is that while the data is written first, the journal writes are completing first on the wire
<eldios>
reading there, seems that data=journal could be the way to go if you don't need extreme performance there
<kentonv>
XgF: well, I'm applying the writes in exactly the order the filesystem passed them to the block device
<kentonv>
but it does make some sense that resize would need to happen before data flush, if it's important to the FS that bytes beyond the end of the file don't somehow end up non-zero
<kentonv>
although I would like that's already very possible to do with mmap() anyway
<XgF>
kentonv: The alternative would be a truncated write
<XgF>
Unless you go data=journaled, you either get truncated writes or zeros, FS picks which
<kentonv>
XgF: yes, I realize one or the other is always possible without data journaling
<kentonv>
but it seems easier to recover from a truncated write than appended zeros in most cases
<kentonv>
because a truncated write will typically look like the file is in a state that it was expected to pass through an some point in time
<kentonv>
like if you killed the program in the middle of it writing
<kentonv>
but a bunch of zeros at the end should never have happened
<XgF>
I suspect that ext4 keeps a cache of "known zero free blocks" to use when expanding a file (because its' totally not cool to let random crap end up inside a file)
<XgF>
In which case it wants to make sure the movement of them blocks from "known zero" to "used" happens before the data hits
<XgF>
But honestly I'm wildly speculating and seriously its' time for bed
<kentonv>
in theory adding blocks to the extent list could be considered separate from changing the size field
<XgF>
Maybe, but it sounds nasty if a file is consuming 1MB but only showing up as 0b
joshbuddy has quit [Quit: joshbuddy]
amyers has joined #sandstorm
amyers has quit [Ping timeout: 256 seconds]
natea has quit [Quit: natea]
joshbuddy has joined #sandstorm
gopar has joined #sandstorm
gopar has quit [Quit: Leaving]
posix4e has joined #sandstorm
<posix4e>
I'm thinking weechat might be better than shout, sandstorm isn't designed around backgrounding random c servers though?
erikoeurch has joined #sandstorm
<posix4e>
by the way my podcast is now running from the word press and media goblin
<posix4e>
hooray sandstorm
ArcTanSusan has joined #sandstorm
darius has quit [Ping timeout: 256 seconds]
ArcTanSusan has quit [Quit: ArcTanSusan]
erikoeurch has quit [Ping timeout: 244 seconds]
joshbuddy has quit [Quit: joshbuddy]
erikoeurch has joined #sandstorm
mort___ has joined #sandstorm
mort___ has quit [Ping timeout: 265 seconds]
natea has joined #sandstorm
natea has quit [Quit: natea]
natea has joined #sandstorm
natea has quit [Quit: natea]
amyers has joined #sandstorm
amyers has quit [Quit: Leaving]
amyers has joined #sandstorm
amyers has quit [Remote host closed the connection]
<paulproteus>
Wow, this is by far the coolest line in this tutorial.
<paulproteus>
Secretly GCE is amazing.
<paulproteus>
OK, by-id/ != by-uuid/
<paulproteus>
So I guess that's not as completely ridiculously great as I was thining, merely super great.
<kentonv>
GCE has some neat features
<paulproteus>
Also I'm not sure you _need_ to partition the swap partition.
dwrensha has quit [Ping timeout: 264 seconds]
dwrensha_ has joined #sandstorm
<kentonv>
I don't know to what extent AWS has the same features. But in my short time using AWS stuff, my impression was that their UX was pretty ugly.
<kentonv>
whereas GCE has always been nice, but then again I'm comparing the GCE command-line with the AWS web UI, so I dunno.
<paulproteus>
jeffmendoza: If you want to retitle your thing to contain "Mobile OS for your cloud server" in the blog post title, then you should post it to news.ycombinator.com !
joshbuddy has joined #sandstorm
<jeffmendoza>
yeah, so when you attach a disk to a vm you can give it a name, and then there will be a symlink /dev/disk/by-id/google-<name> that points to the disk device
<jeffmendoza>
yeah, you could probably use the raw disk, but I like doing the partitioning
<jeffmendoza>
sure, I'll update the link
erikoeurch has quit [Ping timeout: 256 seconds]
<paulproteus>
What do you think of my clickbat title change? (-:
<jeffmendoza>
ok cool, got the @googlecloud retweet