March 17, 2019 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >
March 17, 2019 [00:06:01] <rlaager> DeHackEd: ctime is change time. crtime is creation time, which isn't wired up on Linux's stat(), even for ext4.[00:06:35] <ptx0> yeah, i didn't think anything POSIX kept creation time around[00:07:07] <DeHackEd> ZFS keeps both. zdb can show both, but I've consistently seen ZFS using crtime when I request ctime[00:07:47] <rlaager> I just trivially tested this with: touch foo ; sleep 1 ; chmod 644 foo ; stat foo[00:09:05] <rlaager> Apparently Linux also calls this btime (birth time).[00:09:07] <DeHackEd> and[00:09:08] <DeHackEd> ?[00:22:43] <monsted> you could probably search through the snapdir if that's enabled[00:25:47] <monsted> $ ls -l /var/.zfs/snapshot/*/log/messages[00:25:54] <monsted> ...[00:26:06] <rlaager> So Linux finally seems to have added a statx() syscall in 4.11 that can return btime. glibc added support in 2.28. coreutils has support for statx() in master, as of two weeks ago. ZoL doesn't currently set btime.[00:26:58] <ptx0> 2 weeks ago?[00:27:03] <ptx0> better late than never?[00:30:31] <ptx0> rlaager: zfs does set btime[00:30:38] <ptx0> you can see this with zdb -dddd[00:30:44] <ptx0> we don't have statx support, though[00:30:59] <ptx0> btime is aliased to crtime[00:31:02] <rlaager> ptx0: ZFS _stores_ a creation time, but it's not providing it to userspace as btime through statx().[00:31:06] <ptx0> right[00:31:15] <ptx0> you said it doesn't set it though[00:31:24] <ptx0> :P[01:01:04] *** antranigv <antranigv!uid339677@gateway/web/irccloud.com/x-nwegulsvgyqdibwm> has quit IRC (Quit: Connection closed for inactivity)[01:05:30] <ptx0> tgunr: #8508[01:05:31] <zfs> [zfs] #8508 - Add support for birthtime by ryao <https://github.com/zfsonlinux/zfs/issues/8508>[01:06:55] *** andy_js <andy_js!~andy@94.6.62.238> has quit IRC (Quit: andy_js)[01:32:58] <tgunr> ptx0: thanks[01:59:54] <zfs> [openzfs/openzfs] Merge remote-tracking branch 'illumos/master' into illumos-sync (#749) created by zettabot <https://github.com/openzfs/openzfs/issues/749>[02:35:43] *** Essadon <Essadon!~Essadon@81-225-32-185-no249.tbcn.telia.com> has quit IRC (Quit: Qutting)[04:11:16] *** AndrewG <AndrewG!~andrew@a20.cucumber.me.uk> has quit IRC (Ping timeout: 255 seconds)[04:29:56] *** mifritscher <mifritscher!~mifritsch@mifritscher.de> has quit IRC (Ping timeout: 272 seconds)[09:01:43] *** michaeldexter <michaeldexter!~michaelde@om126208165166.22.openmobile.ne.jp> has joined #openzfs[09:27:19] *** wiedi <wiedi!~wiedi@e-250-067.hrz.tu-chemnitz.de> has joined #openzfs[09:40:45] *** michaeldexter <michaeldexter!~michaelde@om126208165166.22.openmobile.ne.jp> has quit IRC (Quit: michaeldexter)[09:59:42] *** mifritscher <mifritscher!~mifritsch@mifritscher.de> has joined #openzfs[11:49:51] *** andy_js <andy_js!~andy@94.6.62.238> has joined #openzfs[14:05:35] *** v_a_b <v_a_b!~volker@p57A27DBD.dip0.t-ipconnect.de> has left #openzfs[15:08:36] *** Essadon <Essadon!~Essadon@81-225-32-185-no249.tbcn.telia.com> has joined #openzfs[17:00:40] <sindan> Does zfs recv fail if it receives extra garbage past the end of a valid stream? I'm encrypting a stream with aespipe, which pads its input; at decryption the last block will have extra garbage up to the block length.[17:01:11] <sindan> more exactly aespipe pads its output[17:14:40] <monsted> that seems like a pretty terrible encryption tool, if it can't deliver the correct data[17:22:19] <sindan> I use it because it encrypts/decrypts over pipes[17:23:15] <DeHackEd> AES is a 128 bit block stream, so some kind of supplemental metadata would be required for the last block to know how long it actually is or up to 15 extra bytes could be sent.[17:24:26] <DeHackEd> my gut says it would be okay, but I promise nothing[17:26:58] <monsted> there are about a thousand encryption tools that encrypt pipes but don't add random crap[17:28:08] <DeHackEd> does openssl do this? I legit don't know.[17:28:18] <monsted> i'm pretty sure that's one of them[17:28:35] <monsted> the simplest for many uses is to just pipe it through ssh[17:29:11] <sindan> any suggestion that does aes? all I see if I look for "aes encryption over pipes" or similar is aespipe[17:29:53] <DeHackEd> openssl aes-128-cbc [...] (or other, cbc is considered outdated)[17:38:10] <sindan> openssl seems to have a -nopad option[18:03:51] *** wiedi <wiedi!~wiedi@e-250-067.hrz.tu-chemnitz.de> has quit IRC (Quit: ^C)[19:16:13] <monsted> the heck? i got a notice from the bot saying "ZFS native encryption is currently not for PRODUCTION"[19:17:22] <DeHackEd> well Zfs on linux 0.8.0 isn't released yet[19:17:35] <monsted> and i would care because? :)[19:17:51] <DeHackEd> because there's more errata in the last week or two affecting encryption?[19:18:09] <monsted> and i would care because? :)[19:18:28] * monsted strokes his Beastie plushie[20:13:23] *** f_g <f_g!~f_g@213-47-131-124.cable.dynamic.surfer.at> has quit IRC (Ping timeout: 245 seconds)[20:26:42] *** f_g <f_g!~f_g@213-47-131-124.cable.dynamic.surfer.at> has joined #openzfs[20:57:13] *** elxa <elxa!~elxa@2a01:5c0:e085:a261:a27f:b51a:5025:9452> has joined #openzfs[21:22:34] *** elxa <elxa!~elxa@2a01:5c0:e085:a261:a27f:b51a:5025:9452> has quit IRC (Ping timeout: 258 seconds)[21:56:33] *** ct16k <ct16k!~ryan@78.96.221.131> has quit IRC (Quit: What does this button do?)[23:56:14] *** wiedi <wiedi!~wiedi@ip5b4096a6.dynamic.kabel-deutschland.de> has joined #openzfs