search for: 1024b

...7 scares the heck out of me, but I guess that's Microsoft idiocy for you. > If object size were a concern, these features could be implemented in > a new set of functions such that the original stays compact and > intact. It would increase the running memory requirements 50% but > 1024B is so small it shouldn't be a concern. I don't think it matters. > If you feel you want this on the list, feel free to reply on-list. Yes, please. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.

Hello I get the following error when using our Let's Encrypt ssl certificate for webRTC calls : [Jun 2 14:29:28] == DTLS ECDH initialized (secp256r1), faster PFS enabled [Jun 2 14:29:28] ERROR[27360][C-00000ae5]: res_rtp_asterisk.c:1441 ast_rtp_dtls_set_configuration: Specified certificate file '/etc/letsencrypt/live/ws.mydomain.tld/privkey.pem' for RTP instance

...ilable_begin: 47592193024 Available_end: 7721119744 mdir exact used space: 39683908608 mdir guess used space: 39871086592 mdir num mails: 3425033 delta: 1.561232384 G delta / mail: 455 B As you can see, the delta per mail is rather close to the statistically expected values of 2048B, 1024B and 512B. In the end I probably changed my opinion. ~7GB of wasted block space for all my mails is actually quite a lot, but in days of cheap disk space it's acceptable. And with mbox one has IMHO the major disadvantage that mailservers (including dovecot) store some meta-data _in_ it (i.e....

...;def> = COPY %vreg5<kill>; R600_Reg128:%vreg36 R600_Reg32:%vreg5 register: %vreg36 replace range with [976r,992r:1) RESULT: [976r,992r:1)[992r,1024r:0)  0 at 992r 1 at 976r 1008B%vreg37<def> = COPY %vreg6:sel_w; R600_Reg32:%vreg37 R600_Reg128:%vreg6 register: %vreg37 +[1008r,1040r:0) 1024B%vreg10<def> = COPY %vreg36<kill>; R600_Reg128:%vreg10,%vreg36 register: %vreg10 +[1024r,1120r:0) 1040B%vreg10:sel_w<def> = COPY %vreg37<kill>; R600_Reg128:%vreg10 R600_Reg32:%vreg37 register: %vreg10 replace range with [1024r,1040r:1) RESULT: [1024r,1040r:1)[1040r,1120r:0)  ...

...00_Reg128:%vreg36 > R600_Reg32:%vreg5 > register: %vreg36 replace range with [976r,992r:1) RESULT: > [976r,992r:1)[992r,1024r:0)  0 at 992r 1 at 976r > 1008B%vreg37<def> = COPY %vreg6:sel_w; R600_Reg32:%vreg37 > R600_Reg128:%vreg6 > register: %vreg37 +[1008r,1040r:0) > 1024B%vreg10<def> = COPY %vreg36<kill>; R600_Reg128:%vreg10,%vreg36 > register: %vreg10 +[1024r,1120r:0) > 1040B%vreg10:sel_w<def> = COPY %vreg37<kill>; R600_Reg128:%vreg10 > R600_Reg32:%vreg37 > register: %vreg10 replace range with [1024r,1040r:1) RESULT: > [1024...

...eg35 R600_Reg32:%vreg34 > 976B%vreg36<def> = COPY %vreg35<kill>; R600_Reg128:%vreg36,%vreg35 > 992B%vreg36:sel_z<def> = COPY %vreg5<kill>; R600_Reg128:%vreg36 R600_Reg32:%vreg5 > 1008B%vreg37<def> = COPY %vreg6:sel_w; R600_Reg32:%vreg37 R600_Reg128:%vreg6 > 1024B%vreg10<def> = COPY %vreg36<kill>; R600_Reg128:%vreg10,%vreg36 > 1040B%vreg10:sel_w<def> = COPY %vreg37<kill>; R600_Reg128:%vreg10 R600_Reg32:%vreg37 > 1056B%vreg9<def> = COPY %vreg6:sel_z<kill>; R600_Reg32:%vreg9 R600_Reg128:%vreg6 > 1072B%vreg38<def&...

...bination of options. To be used as: rsync -B1024 --copy-devices --no-whole-file \ --stats --progress --inplace dev1 dev2 However I realised that rsync didn't minimise the writes on dev2 at all. In my testing on 100MB ext3 file systems, differing by only about 3 MB (3 MB worth of differing 1024B blocks), rsync would write 30MB worth of data to dev2 (growing the qcow2 file by as much) (and before you ask, the same thing happens with regular files with an unmodified rsync). I wonder if it's not a bug. I started investigating a bit, but the rsync code that handles matching blocks is hard...

...gt;; R600_Reg128:%vreg35 R600_Reg32:%vreg34 976B%vreg36<def> = COPY %vreg35<kill>; R600_Reg128:%vreg36,%vreg35 992B%vreg36:sel_z<def> = COPY %vreg5<kill>; R600_Reg128:%vreg36 R600_Reg32:%vreg5 1008B%vreg37<def> = COPY %vreg6:sel_w; R600_Reg32:%vreg37 R600_Reg128:%vreg6 1024B%vreg10<def> = COPY %vreg36<kill>; R600_Reg128:%vreg10,%vreg36 1040B%vreg10:sel_w<def> = COPY %vreg37<kill>; R600_Reg128:%vreg10 R600_Reg32:%vreg37 1056B%vreg9<def> = COPY %vreg6:sel_z<kill>; R600_Reg32:%vreg9 R600_Reg128:%vreg6 1072B%vreg38<def> = MOV 1, 0,...

An issue was found with the netBeans installer where the installation was failing on a large ZFS filesystem. This resulted in CR 6560644 (zfs statvfs f_frsize needs work). The issue is that large filesystems can cause EOVERFLOW on statvfs() calls. This behavior is documented in the statvfs(2) man page, but I think we can do better. The problem was initially reported against ZFS, and my first fix