Клиентские базы! Email: proda...@armyspy.com Узнайте подробнее!
Клиентские базы! Email: proda...@armyspy.com Узнайте подробнее!
Zdravstvujte! Vas interesuyut klientskie bazy dannyh?
Zdravstvujte! Vas interesuyut klientskie bazy dannyh?
Zdravstvujte! Vas interesujut klientskie bazy dannyh?
Zdravstvujte! Vas interesujut klientskie bazy dannyh?
Big amount of snapshots and disk full
Hi, I am doing backups with rsync and do versioning with btrfs snapshots. And last week I got file system full. I googled some and noticed that there might be bug in space_cache so I cleared cache and mounted it with nospace_cache and system worked about week (managed to delete & create tens of snapshots during that time. Before 1st issue system have worked without problems over year). Now I got same issue again. Any Ideas what I should try next? Disk have never been even half full. An error occurred when script was creating new snapshot, rsync before that was fine. (And there was another rsync to another destination running at same time) Is there some issue with big amount of snapshots? I have nearly 50 machines on backup and most of them have less than ten versions, so my subvol hierarchy is like this. data (btrfsroot) machine1 (subvol) last (subvol) [date] (readonly snapshot of last) [date2] (readonly snapshot of last) ... machine2 (subvol) last (subvol) [date] (readonly snapshot of last) .. root@backuprasia:~# btrfs sub list /data |wc -l 492 root@backuprasia:~# btrfs fi usage /data Overall: Device size: 30.00TiB Device allocated: 13.62TiB Device unallocated: 16.38TiB Device missing: 0.00B Used: 13.59TiB Free (estimated): 16.40TiB (min: 16.40TiB) Data ratio: 1.00 Metadata ratio: 1.00 Global reserve: 512.00MiB (used: 499.00MiB) Data,single: Size:13.45TiB, Used:13.43TiB /dev/mapper/datavg-backup1 13.45TiB Metadata,single: Size:172.01GiB, Used:169.20GiB /dev/mapper/datavg-backup1172.01GiB System,single: Size:4.00MiB, Used:1.62MiB /dev/mapper/datavg-backup1 4.00MiB Unallocated: /dev/mapper/datavg-backup1 16.38TiB root@backuprasia:~# uname -a Linux backuprasia 4.15.0-38-generic #41~16.04.1-Ubuntu SMP Wed Oct 10 20:16:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Nov 02 01:58:31 backuprasia kernel: [ cut here ] Nov 02 01:58:31 backuprasia kernel: BTRFS: Transaction aborted (error -28) Nov 02 01:58:31 backuprasia kernel: WARNING: CPU: 8 PID: 14381 at /build/linux-hwe-4LSUYr/linux-hwe-4.15.0/fs/btrfs/extent-tree.c:3784 btrfs_start_dirty_block_groups+0x260//0x430 [btrfs] Nov 02 01:58:31 backuprasia kernel: [205245.441842] Modules linked in: ip6table_filter ip6_tables ipt_REJECT nf_reject_ipv4 nf_log_ipv4 nf_log_common xt_LOG xt_limit xt_tcpudp xt_multiport iptable_filter ip_tables x_tables intel_rapl sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass intel_cstate 8021q garp mrp mei_me ipmi_ssif stp intel_rapl_perf llc joydev input_leds lpc_ich mei ioatdma shpchp ipmi_si ipmi_devintf ipmi_msghandler acpi_pad acpi_power_meter mac_hid ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs zstd_compress ses enclosure raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid0 multipath linear ast i2c_algo_bit ixgbe ttm crct10dif_pclmul crc32_pclmul drm_kms_helper ghash_clmulni_intel syscopyarea Nov 02 01:58:31 backuprasia kernel: [205245.441911] pcbc sysfillrect aesni_intel sysimgblt fb_sys_fops aes_x86_64 raid1 hid_generic crypto_simd usbhid dca glue_helper mpt3sas ahci ptp raid_class drm r8169 hid mxm_wmi cryptd libahci pps_core scsi_transport_sas mii mdio wmi Nov 02 01:58:31 backuprasia kernel: pcbc sysfillrect aesni_intel sysimgblt fb_sys_fops aes_x86_64 raid1 hid_generic crypto_simd usbhid dca glue_helper mpt3sas ahci ptp rai Nov 02 01:58:31 backuprasia kernel: CPU: 8 PID: 14381 Comm: btrfs-transacti Not tainted 4.15.0-38-generic #41~16.04.1-Ubuntu Nov 02 01:58:31 backuprasia kernel: Hardware name: Supermicro X10DRi/X10DRI-T, BIOS 2.1 09/13/2016 Nov 02 01:58:31 backuprasia kernel: RIP: 0010:btrfs_start_dirty_block_groups+0x260/0x430 [btrfs] Nov 02 01:58:31 backuprasia kernel: RSP: 0018:b7b60efbbdc0 EFLAGS: 00010282 Nov 02 01:58:31 backuprasia kernel: RAX: RBX: 8bd5d4a1bc30 RCX: 0006 Nov 02 01:58:31 backuprasia kernel: RDX: 0007 RSI: 0092 RDI: 8bd77f416490 Nov 02 01:58:31 backuprasia kernel: RBP: b7b60efbbe30 R08: 0001 R09: 0539 Nov 02 01:58:31 backuprasia kernel: R10: R11: 0539 R12: 8bd60128e800 Nov 02 01:58:31 backuprasia kernel: R13: 0001 R14: 8bd1d1ce32a0 R15: 8bd60128e948 Nov 02 01:58:31 backuprasia kernel: FS: () GS:8bd77f40() knlGS: Nov 02 01:58:31 backuprasia kernel: CS: 0010 DS: ES: CR0: 80050033 Nov 02 01:58:31 backuprasia kernel: CR2: 7fc65cfc6868 CR3: 000f8e80a003 CR4: 003606e0 Nov 02 01:58:31 backuprasia kernel: DR0: D
Re: BTRFS for OLTP Databases
W dniu 2017-02-13 o 13:44 PM, Austin S. Hemmelgarn pisze: > On 2017-02-09 22:58, Andrei Borzenkov wrote: >> 07.02.2017 23:47, Austin S. Hemmelgarn пишет: >> ... >>> Sadly, freezefs (the generic interface based off of xfs_freeze) only >>> works for block device snapshots. Filesystem level snapshots need the >>> application software to sync all it's data and then stop writing until >>> the snapshot is complete. >>> >> >> I expect databases to be using directio, otherwise we have problems even >> without using snapshots. Is it still an issue with directio? > It is less of an issue, but it's still an issue because you can still > call for snapshot creation in the middle of an application I/O > request. In other words, the application wouldn't need to worry about > syncing data, but it would need to worry about making sure it's not > actually writing anything when the snapshot happens. > I think this should work the other way around. Snapshot should wait until all directio writes are done, and new requests sent when creating snapshot, should wait until snapshot is done. -- Adrian Brzeziński -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Wrong device?
-version btrfs-progs v4.4 # uname -a Linux backuprasia 4.10.0-26-generic #30~16.04.1-Ubuntu SMP Tue Jun 27 09:40:14 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux ( This usage have been done later after some balance tries.. and mounte to another moun point) # btrfs fi usage /data2 Overall: Device size: 70.95TiB Device allocated: 4.95TiB Device unallocated: 66.01TiB Device missing: 0.00B Used: 4.94TiB Free (estimated): 66.01TiB (min: 33.01TiB) Data ratio: 1.00 Metadata ratio: 2.00 Global reserve: 512.00MiB (used: 0.00B) Data,single: Size:4.77TiB, Used:4.76TiB /dev/md34.77TiB Metadata,DUP: Size:92.00GiB, Used:90.79GiB /dev/md3 184.00GiB System,DUP: Size:32.00MiB, Used:592.00KiB /dev/md3 64.00MiB Unallocated: /dev/md3 66.01TiB PS. I have noticed another bug too, but I haven't tested it with lastest kernels after I noticed that it happens only with compression=lzo. So maybe it is already fixed. With gzip or none compression probem does not happens. I have email server with about 0.5 TB volume. It is using Maildir so it contains huge amount of files. Sometimes some files goes unreadable. After server reset problematic file could be readable again (but not always)... But weird thing is that unreadable file always seems to be dovecot.index.log. I asked from dovecot author, and he said there is nothing special with that file usage, it is just opened with O_APPEND and some data is written to it. Problem is hard to reproduce because it seems to be random -- Ari Saastamoinen -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Клиентские базы Skype: prodawez390 Email: prodawez...@gmail.com Whatsapp: +79139230330
Клиентские базы Skype: prodawez390 Email: prodawez...@gmail.com Whatsapp: +79139230330 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
КЛИЕНТСКИЕ БАЗЫ! Тел\Viber\Whatsapp: +79133913837 Email: aburo...@gmail.com Skype: prodawez389
КЛИЕНТСКИЕ БАЗЫ! Соберем для Вас по интернет базу данных потенциальных клиентов для Вашего Бизнеса! Много! Быстро! Недорого! Узнайте об этом подробнее по Тел: +79133913837 Viber: +79133913837 Whatsapp: +79133913837 Skype: prodawez389 Email: aburo...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
КЛИЕНТСКИЕ БАЗЫ! Тел\Viber\Whatsapp: +79133913837 Email: eteteri...@gmail.com Skype: prodawez389
КЛИЕНТСКИЕ БАЗЫ! Соберем для Вас по интернет базу данных потенциальных клиентов для Вашего Бизнеса! Много! Быстро! Недорого! Узнайте об этом подробнее по Тел: +79133913837 Viber: +79133913837 Whatsapp: +79133913837 Skype: prodawez389 Email: eteteri...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
КЛИЕНТСКИЕ БАЗЫ! Тел\Viber\Whatsapp: KЛИЕHTСKИЕ БAЗЬl! Tел: +791ЗЗ91З8З7 Email: eteteri...@gmail.com Skype: prodawez389 Узнайте подробнее!!!
КЛИЕНТСКИЕ БАЗЫ ДАННЫХ ДЛЯ ПРОДАЖИ ВАШИХ ТОВАРОВ И УСЛУГ! Собираем по интернет под заказ базы данных потенциальных клиентов для Бизнеса! По базе можно звонить, писать, слать факсы и email,вести любые прямые активные продажи Ваших товаров и услуг! Уже завтра огромная клиентская база у Вас, остается только удобным для Вас способом продать Ваши товары и услуги! Узнайте об этом еще подробнее: Тел\Viber\Whatsapp:KЛИЕНTCKИЕ БAЗЬl! Teл: +79I339I3837 Skype: prodawez389 Email: eteteri...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Kernel 3.19 and still "disk full" even though 'btrfs fi df" reports enough room left?
Hello there! I'm stumbling over this regularly. I explicitly upgraded the kernel to avoid this, but it still occurs me every few months: $ touch foo touch: »foo“ kann nicht berührt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar $ sudo btrfs fi df / Data, single: total=101.14GiB, used=78.99GiB System, DUP: total=32.00MiB, used=16.00KiB Metadata, DUP: total=9.00GiB, used=8.48GiB unknown, single: total=512.00MiB, used=832.00KiB Whut? Why? WTF? $ uname -a Linux neptun 3.19.0-31-generic #36~14.04.1-Ubuntu SMP Thu Oct 8 10:21:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux dmesg is empty. Resolution is to delete a whole bunch of btrfs subvolumes which are produced by apt-btrfs-snapshot. I run a sudo btrfs balance start -dusage=5 / afterwards as part of my regular "i have no clue what the heck is wrong with this; maybe it will help & mend my problem" process. This is annoying. Why is even btrfs own "disk free" utility lying to me? How to fix this? How to avoid this? How to get notified about this? - Ben P.S.: Just as user feedback: For /srv I'm using on the very same system ZFS since the very first day. With snapshots & all the fancy stuff like ZRAID-1, lz4, ... My number of Issues there: 0 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel 3.19 and still "disk full" even though 'btrfs fi df" reports enough room left?
Many thanks to everybody on the list for the awful a lot help I received. I'm impressed by the amount, quality and speed of the responses I received! > See the FAQ[1] for how to interpret the output. ... Very helpful, thanks. > The solution is to free up some of the data allocation, using a filtered > balance. As noted in my original post, this is already part of my "voodoo" I'm doing in these situations. Will newer kernel relieve me from this burden? FYI: On executing "btrfs fi show" the first time after I deleted many snapshots and did a filtered (-dusage) balance, it reported sth. like devid1 size 119.21GiB used 117.03GiB now (after a unfiltered balance?) it reports devid1 size 119.21GiB used 66.06GiB I'm really confuzzled. > [..] Ubuntu repeatedly chooses to stabilize on exactly the wrong kernel > versions. > .. > Give http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.1.13-wily/ a try. Could not agree more. Will give wily kernel a try. > The output is really a little confusing. [..] should make the output more > understandable. +1 Considering that the status of a file systems should be understandable by regular users, it would be great if the btrfs tools could provide additional user hints like _"I seems your metadata space is running out of space. Please run `foo bar` to resolve this situation or consult FAQ[4] for more details"_. Austin Hemmelgarn commented on my ZFS comparison. His argument sound very vigilant taking into account the benefit of a GPL-compliant FOSS FS like btrfs vs. a stabilized ZFS. The thing I appreciate in ZFS as user most, is the very user friendly interface of it's tools. Just have a look at the following output: # zpool status Permission denied the ZFS utilities must be run as root. # sudo zpool status pool: zfstank state: ONLINE status: Some supported features are not enabled on the pool. The pool can still be used, but some features are unavailable. action: Enable all features using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not support the features. See zpool-features(5) for details. scan: scrub repaired 0 in 23h56m with 0 errors on Mon Aug 31 01:21:26 2015 config: ... errors: No known data errors This output is totally self explaining. In case of errors, ZFS will simply lists the broken files and tell you about your options to resolve the issue (restore backup, overwrite, delete). It uses easy terms & guides me in many places. In contrast the terminology in btrfs (DUP, Metadata, Global Reserve) is rather intimidating, and as already stated, the output to a simple command like "disk free" rather difficult to understand. But btrfs seems to make progress here. Again thanks for all the helpful feedback here on the list! I'm still a bit puzzled how to avoid my situation in the first place. Should I pick "btrfs show" in favor to "btrfs fi df" to learn about an impending "disk full" situation? Will newer kernels do the balance on their own? -Ben -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel 3.19 and still "disk full" even though 'btrfs fi df" reports enough room left?
>It's just freed up lots of space. You'll probably find that your > "total" value for data in btrfs fi df is close to (but not exactly) 66 > GiB now, if you've just run a full unfiltered balance. (The difference > being made up of metadata). I think i need to dive more into the details of btrfs to finally grasp the details here >There's a repo of "useful btrfs scripts" that David Sterba looks > after. Great pointer! I think you refer to https://github.com/kdave/btrfsmaintenance and it indeed looks very promising. >> Should I pick "btrfs show" in favor to "btrfs fi df" to learn about an >> impending "disk full" situation? >In the general case, you need both of them to make sense of it. Duh I'll better... ehh... try to find some backported btrfs-profs supporting `usage`. >> Will newer kernels do the balance on their own? >I think it's on the "projects" list on the wiki [..] aware of anyone > working on it. Ok - which is another +1 for looking at David 's repo. Thanks! - Ben -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel 3.19 and still "disk full" even though 'btrfs fi df" reports enough room left?
On Thu, Nov 19, 2015 at 07:45:13PM +0100, Ben Tebulin wrote: > > >It's just freed up lots of space. You'll probably find that your > > "total" value for data in btrfs fi df is close to (but not exactly) 66 > > GiB now, if you've just run a full unfiltered balance. (The difference > > being made up of metadata). > > I think i need to dive more into the details of btrfs to finally grasp > the details here > > >There's a repo of "useful btrfs scripts" that David Sterba looks > > after. > > Great pointer! > I think you refer to https://github.com/kdave/btrfsmaintenance and it > indeed looks very promising. > > >> Should I pick "btrfs show" in favor to "btrfs fi df" to learn about an > >> impending "disk full" situation? > >In the general case, you need both of them to make sense of it. > > Duh I'll better... ehh... try to find some backported btrfs-profs > supporting `usage`. It's not massively more helpful -- you still need to understand the relationships. It just uses slightly different language, and puts all the information in one output instead of two. You start with a load of unused space -- that's the "total" for each device in btrfs fi show. That space is allocated to specific usages as the FS needs it. The allocated space is the "used" in btrfs fi show for each device. Then we switch to looking at btrfs fi df. The "total" values are the amount of the *allocated* space given to each type of storage. Within those, actual stuff is stored (like your files), which is the "used" value for each kind of storage. If you've ever played SimCity, the allocation process is like zoning -- you say what kind of thing can go on the space, but it's not actually used until something gets built on it. The problem you hit is when everything has been allocated, and there's a need for more metadata space (usually), and there's lots of unused data space. The balance operation moves some things around so that some of the unused data allocation can be freed up, giving the FS the ability to allocate more metadata space. Hugo. > >> Will newer kernels do the balance on their own? > >I think it's on the "projects" list on the wiki [..] aware of anyone > > working on it. > > Ok - which is another +1 for looking at David 's repo. > > Thanks! > - Ben -- Hugo Mills | 2 + 2 = 5, for sufficiently large values of 2. hugo@... carfax.org.uk | http://carfax.org.uk/ | PGP: E2AB1DE4 | signature.asc Description: Digital signature
Re: Kernel 3.19 and still "disk full" even though 'btrfs fi df" reports enough room left?
This explanation helped a lot. Got it now! Thank you! >You start with a load of unused space -- that's the "total" for > each device in btrfs fi show. That space is allocated to specific > usages as the FS needs it. The allocated space is the "used" in btrfs > fi show for each device. > >Then we switch to looking at btrfs fi df. The "total" values are > the amount of the *allocated* space given to each type of storage. > Within those, actual stuff is stored (like your files), which is the > "used" value for each kind of storage. > >If you've ever played SimCity, the allocation process is like > zoning -- you say what kind of thing can go on the space, but it's not > actually used until something gets built on it. > >The problem you hit is when everything has been allocated, and > there's a need for more metadata space (usually), and there's lots of > unused data space. The balance operation moves some things around so > that some of the unused data allocation can be freed up, giving the FS > the ability to allocate more metadata space. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel 3.19 and still "disk full" even though 'btrfs fi df" reports enough room left?
Am 20.11.2015 um 04:14 schrieb Duncan: > Meta-comment: > > Apparently that attribution should actually be to Hugo Mills. I've no > idea what went wrong, but at least here as received from gmane.org, the > from header really does say linux-btrfs.tebulin, so something obviously > bugged out somewhere! Meta-Answer: My fault I accidentally exposed my spamgourmet proxy address to Hugo by taking him CC. He replied to all assuming it would go directly to the list, but the proxy address masked his original address an put id in it. Sorry for messing up! -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
КЛИЕНТСКИЕ БАЗЫ! Тел\Viber\Whatsapp: +79139393506 Email: mgordee...@gmail.com Skype: prodawez389
КЛИЕНТСКИЕ БАЗЫ! Соберем для Вас по интернет базу данных потенциальных клиентов для Вашего Бизнеса! Много! Быстро! Недорого! Узнайте об этом подробнее по Тел: +79139393506 Viber: +79139393506 Whatsapp: +79139393506 Skype: prodawez389 Email: mgordee...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
★webmaster--10月·广州国际进出口汽车配件展【与“广交会”同期同地举行】 （地右P1-L-Me）
webmaster【通过本邮件参展优惠500元一展位，需回信专用邮箱“12809...@qq.com”报名】 尊敬的 企业领导/公司负责人： 诚邀参加中国最大汽配外贸展 —— APF 2017 汽配行业品牌盛会，外贸企业最佳选择，全球采购首选平台！ ★ 与“广交会”同期同地举行， ★ 以“广交会”庞大的客流量为依托，买家互动，借势兴展， ★ 共享来自全球数十万采购商资源••• 【 基 本 信 息 】 中文名称： 2017广州国际进出口汽车配件展览会 英文名称： The Guangzhou International Import and Export Auto Parts Fair 2017 （APF 2017） 展会日期： 2017年10月13—15日 展会场馆： 广州琶洲国际采购中心 批准单位： 中华人民共和国商务部 主办单位： 中国对外贸易经济合作企业协会、映德国际会展有限公司 官方网站： http://www.CAPE-china.com 在线客服： 邮箱/QQ：q...@12809395.com； 微信：ZhanShangZhiJia； 微博：http://weibo.com/yingdehuizhan 咨询电话： 4000-580-850（转5206或8144）； 131-2662-5206； 010―8699-7155、 8084-2128； 【 展 会 介 绍 】 中国目前的汽车保有量已达1.95亿多辆，预计到2020年，中国汽车保有量将超过2.5亿辆。预计2016年中国汽车年产销量将超过3000万辆，到2020年中国汽车产销量将分别超过4500万辆，从而成为名副其实的全球第一大汽车市场。汽车配件是汽车工业发展的基础，汽车配件配套及售后服务市场是汽车市场的重要组成部分，中国汽车工业的迅猛发展，为汽车配件行业提供了坚实的产业基础和有力的市场支撑，并将形成1.5-2万亿元超大规模的市场产值。 作为汽车市场的焦点，广州拥有国内最大的汽车生产基地和汽车产业集群，连续三年汽车消费增速全国前列。2017年是“十三五”规划实施的重要一年，是供给侧结构性改革的深化之年，中国汽车工业已步入由大到强的发展之路，行业资源分配日益优化、产业布局日趋合理的态势已初现端倪，产业发展正逐步由产销量的提升演变为质量的飞跃。尤其在夯实产业根基、促使健康发展原则指导下，汽车配件产业，已被提升为汽车产业链条中首要的发展对象，资源倾斜、政策扶持、整顿规范，可以预计，继我国整车生产及消费在过去十年取得蓬勃发展成就之后，未来五到十年，将是我国汽车配件行业产生根本性变革的黄金时期。 得益于中国汽车产业高速发展和全球汽车零部件产业链积极向中国转移，映德会展、中汽展览联合行业权威机构定于2017年10月13-15日在广州琶洲国际采购中心举办“2017广州国际进出口汽车配件展览会”（APF 2017）。依托汽车产业和全球最大的潜在市场资源，根据汽车配件产业发展现状和中外市场需求，在继承和延伸往届展会成功经验的基础上，在各级政府部门、行业协会的关心与支持下、经过主承办单位的精心组织策划，“APF 2017”将以全新的面貌再现广州，展会将全面展示汽车领域的最新产品与成果及未来发展方向，将有超过百家合作媒体的超大阵容作全方位的立体宣传。APF 全国统一参展报名热线：4000-580-850（转5206、8144）。 我们将继续以“突出品牌、开拓创新、注重实效、强化服务”的办展宗旨，凭借独特的创意，科学的组织管理和卓越的服务，以全新的理念为广大中外参展商提供一个“专业化、国际化、品牌化”的展示交流平台，为全球汽车配件及后市场行业提供更多的合作机会，有力推动中国汽车配件产品全面进入全球采购体系，与世界各国汽车产业协调合作、互利共赢、共同发展进步。 【 展 会 优 势 】 ●绝佳商机 —— APF 2017举办时间正值“广交会”期间，享有“中国第一展”美誉的“广交会”，每年参加的采购商大约20多万，来自一百多个国家和地区。我们将通过一系列途径充分借助“广交会”全球买家的巨大资源，并通过组委会客户关系邀请系统向国内外三十多万采购商发出邀请，与“广交会”完全互动，借势兴展，同时弥补“广交会”内销的不足，形成“一内一外、相辅相成”的作用。以“广交会”庞大的客流量为依托，中外采购商云集，市场潜力不可估量，巨大商机全面彰显，是开拓国际市场的重要平台！ ● 黄金地段 —— 广州琶洲国际采购中心与广交会展馆一路之隔，连为一体，形成完美对接，连接广交会同类产品展区，距离地铁八号线琶洲站A出口仅200米之遥，交通非常便利，方便海外客商前来参观、采购。 ● 参展回报 —— 与每个国内外采购决策者面对面交流，和意向客户达成交易，在专业客户中扩大品牌影响力；建立海外分销网络，拓展国际市场；新产品、新技术推广；开拓新市场；了解竞争对手及行业发展趋势；洞悉国际最新技术与资讯；约见老客户并发展新业务。 【 目 标 观 众 】 中国（广州）国际汽车零部件及用品展览会组委会（映德会展―YOND EXPO）将专业观众组织和媒体宣传作为工作重点，邀请中外汽车制造商、改装厂、改装行、改装店，汽车工业设备制造商、汽车零配件用品制造商、贸易商、代理商、经销商、终端用户，汽车配件用品市场、超市、连锁加盟店、4S店，汽车保养及美容中心、汽车维修中心、汽车修理厂，汽车综合性能检测站、汽车后市场经销商，汽车后市场连锁经营领域专家、学者、投资公司及国内外有志于汽车后市场投资创业人士、汽车服务行业、汽车爱好者、车友会、俱乐部、商务机构、汽车维修检测行业相关部门、汽车交通运输部门、政府主管部门、汽车行业协会、专业媒体等主要单位及负责人参会。采取卓有实效的措施为参展企业搭建交流与合作的平台，促进科技成果转化，提高企业市场竞争力；同时通过系列紧密有序的宣传活动，确保展会在国内外引起最大关注。 16万国内外专业买家云集羊城 —— 一、 国内专业买家 1、300家整车厂和汽车销售公司 - 本田（广州，东风），丰田（一汽，广汽），大众（一汽，上海），北京现代，上海通用，东风日产，长安福特，比亚迪，奇瑞等35家主流整车企业和60家汽车销售公司，汽车用品公司的采购负责人现场参观采购。 2、8000家4S店集团及全国4S店 - 新疆广汇，冀东庞大，上海永达，浙江物产元通，广物汽贸，东创建国，大连中升，湖南申湘，深圳深业，中汽西南，安徽亚夏，郑州豫华等300家4S店集团和中国各品牌4000家4S店采购负责人参展采购。 3、1500家全国一级批发物流商 - 欧特隆（辽宁，杭州，南京，山西），沈阳新天成，郑州二仟家，山西茂德隆，长沙湘泸，福建永联，成都穗丰，广州永丰，新疆半分利，北京派安，石家庄中惠等1200家一级批发物流参展采购。 4、7000家全国各地市代理经销商 5、2500家全国优质影音改装专业店 - 以新城子昂，上海车之宝，北京双周，音乐前线，先歌兄弟， 非常城市等为代表的全国各区域优质影音改装店参展采购。 6、300家大型零售终端连锁 - 以新奇特，黄帽子，上海美车饰等为代表的全国各区域优质零售终端及大型连锁参展采购。。 7、9家国内终端零售店（含南方/泛珠三角地区终端店3家） - 以金手指，车元素等为代表的福建，江西，湖南，广东，广西，海南，四川，贵州，云南，香港，澳门等泛珠三角地区零售终端现场采购。以及2万家全国优秀零售终端。 二、 国外专业买家 1、4000亚洲买家： - 包括日本、韩国、印度尼西亚、马来西亚、印度、泰国、菲律宾、越南、新加坡等国行业商会组团采购参观。 2、1500中东买家： - 包括阿联酋、沙特阿拉伯、伊朗、叙利亚、以色列、科威特、卡塔尔、也门等国采购商组团参观采购。 3、2500欧美买家： - 包括德国、英国、法国、美国、墨西哥、加拿大等国采购商采购参观。 【 展 品 范 围 】 汽车零部件、零配件，发动机系统、底盘系统、制动系统、行驶系统、转向系统、车身系统、传动系统、排气系统、散热冷却系统、燃油系统，汽车附件、通用件、紧固件、密封件、摩擦材料，汽车电机、轴承、蓄电池、滤清器、散热器、消声器、传感器、仪器仪表、雨刷器、变速器、离合器、离合片、刹车片、汽车弹簧、减震器、保险杠、安全气囊、座椅、玻璃、车镜、车灯、汽车空调、轮胎、轮毂、链条、防滑链，汽车线束、插接器、硬管、软管、软轴、拉索，车用纺织品，汽车油漆、润滑油、机油、添加剂，汽车用品，汽车电子电器，汽车音影、音响、导航、车载通讯、安全和防盗系统，汽车改装部件及用品，汽保设备及工具，汽车模具，汽车零部件制造技术、设备、工具及材料，汽车零部件清洗设备及包装，汽车新产品，汽车节能环保与新能源技术及产品，相关软件、媒体、认证、金融和保险机构等。 【 参 展 细 则 】 ◆ 展位规格： 1、特装展位：36平方米起租，仅提供相应面积室内外空地。展台搭建、展览器具、用电用水等自理。 2、标准展位：9平方米（3m×3m）每个，2.5m高壁板、一条楣板（展商名称）、一张洽谈桌、两把椅子、两盏射灯、220V/5A电源插座一处。 ◆ 展位费用： 特装展位：境内企业RMB2000/平方米； 境外企业USD500/平方米； 标准展位：境内企业RMB2/个； 境外企业USD5000/个； （双面开口标准展位另加收10%费用） ◆ 会刊广告： （大会《会刊》将帮助您在展会后找到客户！除在展会期间广为发送外，还通过各种有关渠道发送给未能前来参观展会的各地专业人士手中，他们可利用会刊迅速查找服务内容与联络方法。 会刊尺寸：130mm*210mm，进口铜板纸彩色精印，发行量10万册。） 封面 CNY 3； 封二封三 CNY 22000； 扉页 CNY 18000； 黑白页 CNY 5000； 封底 CNY 2； 彩页跨版 CNY 18000； 彩页 CNY 12000； 300字简介 CNY 2000； ◆ 会议论坛： 如技术交流会/产品推广发布会，CNY9000/小时/场，用于会场及相关设备租金（包括场地、扩音设施、灯具、投影机、投影仪，桌椅、空调、茶水并协助主讲企业组织听众）。 【 参 展 程 序 】 1、大会即日起开始接受厂商报名，组委会（映德会展―YOND EXPO）严格按“款到先后顺序优先安排展位”，先期报名参展企业除“在统一参展费用的基础上获得较靠前展台位置”的同时，并可享受更多“展前宣传”和“买家推介”等增值服务。 2、参展单位请详细填写《参展申请表》（备索）并加盖公章，传真或复印后寄送至大会组织办公室（映德会展―YOND EXPO），并于三个工作日内向大会指定账户汇出参展费用。 3、参展单位请于报名时将300字内企业简介同时提供至大会组织办公室，以便进行及时展前宣传和刊登《会刊》等。 4、展品运输、仓储、吊装，展商报道、接待、食宿等后勤服务，详见会前《参展商手册》，约在大会开幕前一个半月发送。 5、需用动力电、气或用水、特装展台装修等事宜，请于大会开幕前一月将有关资料提供给大会组委会，以便会务组协助参展企业做好相应安排。 6、组委会拒绝与参展范围不符的厂商参展。报名截止日期：2017年08月31日。 【 筹 展 联 络 】 广州国际进出口汽车配件展组委会 官方网站： http://www.CAPE-china.com 全国统一客服热线： 4000-580-850.（分机：8144、5
★ lintaowenxue --“2018世界复合材料展览及会议”将于“3月”在“法国巴黎”举行 （地右P1-L-Me）
尊敬的 lintaowen...@163.com 企业领导/公司负责人/业界专家，您好： 新材料为21世纪三大共性关键技术之一，已成为全球经济迅速增长的源动力和提升核心竞争力的战略焦点。材料作为制造业的基础，特别是新材料研究和产业发展的水平与规模，已经成为衡量一个国家科技进步和综合实力的重要标志。在新材料发展与应用中，复合材料占有相当重要的地位，特别广泛的应用在汽车、交通、风能、航空、航天、兵器、船舶、国防、机械、电子、化工、建筑、农业、渔业、纺织、运动器材等领域，一直是世界各国优先发展和竞争激烈的重要行业。 “JEC世界复合材料展览及会议”（JEC world Composites Show & Conferences）创办于1963年，每年举办一届，至2017年总共举办了52届，主办单位是法国JEC复合材料发展促进会/JEC集团，中国总展团展商组织单位为映德国际会展集团中国代表处，在北京、上海等地设有分支机构，负责该展会在中国的推广和招商工作（JEC中国总展团报名热线：4000-680-860转8144、5220）。JEC复合材料展已成为世界上历史最悠久、规模最大的复合材料行业专业展览会，展示和反映了当前复合材料行业的最新技术和应用成果。 为了增进国内外复合材料行业的交流与合作，同时展示我国复合材料产业的发展与成就，帮助境内企业开拓国内外市场，中国国际复材协会、映德国际会展集团（YOND EXPO）中国代表处已近十年组织中国企业参与该展会，为中国复合材料集团、中材科技、中钢集团、中国建材集团、中国商飞、北京玻钢院、上海杰事杰新材料集团、重庆国际复合材料、中南控股集团、秦皇岛耀华玻璃钢、烟台氨纶、天马集团、华东理工大学、哈尔滨工业大学、巨石集团、中冶集团、金光集团、江苏恒神纤维材料、重庆大学、上海玻璃钢研究院、中南大学、哈尔滨玻璃钢研究院等众多行业巨头和知名机构提供了优质高效的境外展贸服务。 “JEC world 2018 第五十三世界复合材料展览及会议”将于“3月06-08日”在“法国巴黎展览会议中心”再度举行，我们诚邀全国各地复合材料及新材料相关单位与业界人士加入咱们的中国总展团前往参展参观。 有关参展参观“JEC世界复合材料展”事宜，请联络【中国总展团】组办方—— 全国统一客服热线：4000-580-850（转5220、8144、）、010—6923-6944； 邮箱/QQ：12809395#qq.com； 微信： CanZhanXiaoXi（参展消息）、ZhanShangZhiJia（展商之家）； 微博：http://weibo.com/jecshow（展会）、http://weibo.com/yingdehuizhan（公司）。 参加JEC展会是一个复合材料及新材料企业走向国际化的标志和途径！ __ （百万群发系统|为您发送|如不希望再收到此行业资讯|请回复“TD+JEC”至邮箱1055800...@qq.com）
