http://permalink.gmane.org/gmane.linux.file-systems hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.linux.file-systems/64701 <pre>Email :sniperxsystem&lt; at &gt;support.com Friend Name :Friend Friend Email :linux-fsdevel&lt; at &gt;vger.kernel.org comment : Listen to this... pretty crazy... So many people rushed to download this $530k/year system yesterday... That they crashed the ENTIRE server! =&gt;&gt;http://www.sniperxsystem.com/?code=4fbea9cb964f6&lt;&lt;= (The site was down ALL day) Pretty crazy. ... The "ghetto" video alone has sent shockwaves through the Clickbank community. Can you believe THIS guy's one of Clickbanks biggest super affiliates? =&gt;&gt;http://www.sniperxsystem.com/?code=4fbea9cb964f6&lt;&lt;= Talk soon P.S. This is **BRAND NEW**... It works and it's made $1,549.87 a DAY for the past 739 days in a ROW! No PPC, no PPV, no CPA, no so-called 'push button softwares' scams, no 'loopholes'... Something TOTALLY different. Check it out (fast, while it's still open): =&gt;&gt;http://www.sniperxsystem.com/?code=4fbea9cb964f6&lt;&lt;= -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to major</pre> sniperxsystem< at >support.com 2012-05-26T01:12:03 http://permalink.gmane.org/gmane.linux.file-systems/64700 <pre> Ok, that is certainly fair. I'm not _terribly_ worried about the performance impact but it's certainly possible performance will require some more work, we do need that testing. What's also going to help with performance is for stacking block devices (and possibly drivers at some point) to be changed to handle arbitrary sized bios, so the splitting code in generic_make_request() can be disabled for them - that should also be pretty easy at this point. I have some other ideas/cleanups that should improve performance too but I'll leave that for later. I really do care deeply about performance - and it's been my experience that really the most important thing for performance is clean, simple code and interfaces - much more than people seem to generally assume, too... -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Kent Overstreet 2012-05-26T00:18:56 http://permalink.gmane.org/gmane.linux.file-systems/64672 <pre>Since generic_make_request() can now handle arbitrary size bios, all we have to do is make sure the bvec array doesn't overflow. Signed-off-by: Kent Overstreet &lt;koverstreet&lt; at &gt;google.com&gt; --- fs/bio.c | 133 ++++++++++++-------------------------------------------------- 1 file changed, 26 insertions(+), 107 deletions(-) diff --git a/fs/bio.c b/fs/bio.c index e4d54b2..b0c2944 100644 --- a/fs/bio.c +++ b/fs/bio.c &lt; at &gt;&lt; at &gt; -570,12 +570,22 &lt; at &gt;&lt; at &gt; int bio_get_nr_vecs(struct block_device *bdev) } EXPORT_SYMBOL(bio_get_nr_vecs); -static int __bio_add_page(struct request_queue *q, struct bio *bio, struct page - *page, unsigned int len, unsigned int offset, - unsigned short max_sectors) +/** + *bio_add_page-attempt to add page to bio + *&lt; at &gt;bio: destination bio + *&lt; at &gt;page: page to add + *&lt; at &gt;len: vec entry length + *&lt; at &gt;offset: vec entry offset + * + *Attempt to add a page to the bio_vec maplist. This can fail for a + *number of reasons, such as the bio being full or target block device + *limitations. The target b</pre> Kent Overstreet 2012-05-25T20:25:37 http://permalink.gmane.org/gmane.linux.file-systems/64668 <pre> No, it wasn't in principle. There were some comments I haven't addressed yet. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Rafael J. Wysocki 2012-05-25T19:13:50 http://permalink.gmane.org/gmane.linux.file-systems/64667 <pre>Email :danniel&lt; at &gt;gmail.com Friend Name :Friend Friend Email :linux-fsdevel&lt; at &gt;vger.kernel.org comment : Hi Friend, I'm sure you already found out the rumours that some people make their own energy. Some of them slash the energy bill by half. Some of them cut the bill completely. Some even make the electric company pay them(!). That's why I was ecstatic when I found this website: http://www.greenhomemade.com/?code=4fbd5d3bbfcd4 I read every single word, and boy... this stuff really got me all curious. It seems it's actually very easy and cheap to build and use a renewable energy system. Anyway, I went ahead and bought their package. I couldn't resisted... It sounds too good to be true, yet if this turns out to be "real", then this is BIG. I'm so enthusiasted about this, that I thought to just send you a link so you get to see it for yourself: http://www.greenhomemade.com/?code=4fbd5d3bbfcd4 To a better life, Danniel Guedotte PS: Friend, they give a 60-day guarantee. You risk nothing. B</pre> danniel< at >gmail.com 2012-05-25T18:54:21 http://permalink.gmane.org/gmane.linux.file-systems/64664 <pre> Did this patch ever wind up going anywhere? Fedora has it sitting in our tree with a comment that says "rebase" and I don't see it in the linux-next tree at all. Did if fall through the cracks or was it NAKed somewhere? josh -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Josh Boyer 2012-05-25T16:55:10 http://permalink.gmane.org/gmane.linux.file-systems/64663 <pre>Sayin ilgili, Biz 10 yili askin bir süredir internet üzerinden profesyonel olarak CEVIRI / TERCUME HIZMETLERI veren bir kurulusuz. Kurulusumuzun 10. yili serefine firmalara ozel, sayfasi 12 TL+KDV'lik bir kampanya hazirladik. Sadece INGILIZCE - TURKCE ve TURKCE - INGILIZCE cevirilerde gecerli olan ve kisa bir sure devam edecek bu cazip fiyat avantajindan yararlanmak icin lutfen bizi hemen simdi arayiniz veya bir e-posta gonderiniz. Diger diller icin lutfen fiyat sorunuz. Not: 1 sayfa = 1000 karakter veya 180 kelimelik dunya standardi esas alinmistir. Teknik metinlerde %25 fark alinacaktir. Diger diller icin lutfen fiyat aliniz. Saygilarimizla, Levent Turer, Genel Koordinator Turer Ceviri Hizmetleri e-posta: info&lt; at &gt;turerceviri.com web: www.turerceviri.com Tel: 0232 421 13 60 Faks: 0232 421 13 32 Bu e-mail size otomatik olarak, yani bir reklam amaciyla rastgele gonderilmemistir. Eger bizden bu veya benzeri bir konuda bir daha e-posta almak istemiyorsaniz, lutfen bize bildiriniz. Size ra</pre> info< at >turerceviri.com 2012-05-23T13:14:17 http://permalink.gmane.org/gmane.linux.file-systems/64656 <pre>Email :danniel&lt; at &gt;gmail.com Friend Name :Friend Friend Email :linux-fsdevel&lt; at &gt;vger.kernel.org comment : Hi Friend, I'm sure you already found out the rumours that some people make their own energy. Some of them slash the energy bill by half. Some of them cut the bill completely. Some even make the electric company pay them(!). That's why I was ecstatic when I found this website: http://www.greenhomemade.com/?code=4fbd5d3bbfcd4 I read every single word, and boy... this stuff really got me all curious. It seems it's actually very easy and cheap to build and use a renewable energy system. Anyway, I went ahead and bought their package. I couldn't resisted... It sounds too good to be true, yet if this turns out to be "real", then this is BIG. I'm so enthusiasted about this, that I thought to just send you a link so you get to see it for yourself: http://www.greenhomemade.com/?code=4fbd5d3bbfcd4 To a better life, Danniel Guedotte PS: Friend, they give a 60-day guarantee. You risk nothing. B</pre> danniel< at >gmail.com 2012-05-25T15:34:39 http://permalink.gmane.org/gmane.linux.file-systems/64649 <pre> Okay. I'll do a separate label cleanup patch. We need to check nd-&gt;inode-&gt;i_mode *after* the lookup. So top of the function is not a good place. Right, that appears to be a bug. Thanks for spotting. Yeah, moving to the bottom sounds like a good cleanup. Yes, will do a cleanup patch. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Miklos Szeredi 2012-05-25T15:12:01 http://permalink.gmane.org/gmane.linux.file-systems/64648 <pre> We call security_path_mknod() before -&gt;atomic_open() in may_o_create(). There's no audit_inode() on the created dentry neither in the original code nor in the modified code. But that may be a bug regardless, it's just independent of my changes. At least AFAICS. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Miklos Szeredi 2012-05-25T14:58:46 http://permalink.gmane.org/gmane.linux.file-systems/64644 <pre>Email :sniperxsystem&lt; at &gt;support.com Friend Name :Friend Friend Email :linux-fsdevel&lt; at &gt;vger.kernel.org comment : Listen to this... pretty crazy... So many people rushed to download this $530k/year system yesterday... That they crashed the ENTIRE server! =&gt;&gt;http://www.sniperxsystem.com/?code=4fbea9cb964f6&lt;&lt;= (The site was down ALL day) Pretty crazy. ... The "ghetto" video alone has sent shockwaves through the Clickbank community. Can you believe THIS guy's one of Clickbanks biggest super affiliates? =&gt;&gt;http://www.sniperxsystem.com/?code=4fbea9cb964f6&lt;&lt;= Talk soon P.S. This is **BRAND NEW**... It works and it's made $1,549.87 a DAY for the past 739 days in a ROW! No PPC, no PPV, no CPA, no so-called 'push button softwares' scams, no 'loopholes'... Something TOTALLY different. Check it out (fast, while it's still open): =&gt;&gt;http://www.sniperxsystem.com/?code=4fbea9cb964f6&lt;&lt;= -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to major</pre> sniperxsystem< at >support.com 2012-05-25T01:26:47 http://permalink.gmane.org/gmane.linux.file-systems/64643 <pre>Hi, Tejun and Jens On 05/23/2012 10:54 PM, Asias He wrote: Ping. </pre> Asias He 2012-05-25T01:16:47 http://permalink.gmane.org/gmane.linux.file-systems/64637 <pre> Ahh, I saw that comment but I missed what it was that you wanted me to reorder. Will do. Yeah, I'll do that. Yes. Yes. Not masking out __GFP_WAIT would only be safe if you could guarantee that you never tried to split a bio more than once (from the same bio set), and IMO that'd be a terrible thing to rely on. When what's not the same? They are. I agree that it is hacky, but shifting the responsibility onto the caller would IMO be much more likely to lead to buggy code in the future (and those deadlocks are not going to be easy to track down). It might be better to mask out __GFP_WAIT in bio_alloc_bioset(), I'm not sure. Doesn't matter. If you allocate a split, it won't free itself until the IO is submitted and completes; current-&gt;bio_list != NULL the bio cannot complete until you return. Yeah, caller responsibility. Will do. I thought about that, but this works for now - my preferred solution is to make bi_io_vec immutable (that'll require a bi_bvec_offset field in struct bio, and the en</pre> Kent Overstreet 2012-05-24T21:27:23 http://permalink.gmane.org/gmane.linux.file-systems/64636 <pre> OK, no problem -- if anything I'm glad to have verification that this change is not needed. Cheers, -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Matt Helsley 2012-05-24T20:32:04 http://permalink.gmane.org/gmane.linux.file-systems/64628 <pre> [..] Is this code correct. Now original code might clone bio after split and new code will clone the original bio itself and not the split one? Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Vivek Goyal 2012-05-24T18:59:19 http://permalink.gmane.org/gmane.linux.file-systems/64625 <pre>Hello, all. I've looked into how Mac OS X compresses files using "transparent compression". Since I don't plan to use this data now, I've thought it may be a good idea to document my findings, perhaps someone may implement compressed reader. It's conceptually and in implementation very similar to zisofs. I suppose that reader is familiar with http://developer.apple.com/legacy/mac/library/#technotes/tn/tn1150.html Used compression: zlib Block size: 64K Missing bits from TN1150. Attributes key (big-endian): uint16_t | unknown | always zero uint32_t | cnid | file id of parent, most likely, not checked uint32_t | unknown | always zero uint16_t | namelen | length of name uint16_t[] | name | name in UTF-16BE Attributes header (start of the value in attributes key), (big-endian): uint8[3] | unknown | always zero uint8_t | type | only 0x10 = inline is used for com.apple.decmpfs, attribute itself follows uint32_t | unknown | always zero uint64_t | size | size of attribute Compressed att</pre> Vladimir 'φ-coder/phcoder' Serbinenko 2012-05-24T18:38:35 http://permalink.gmane.org/gmane.linux.file-systems/64618 <pre> Again could you please take this bio_split and just put it down below the implementation of bio_pair_split. This way we can better review what the changes actually are. Now it is a complete mess in the diff, where the deleted lines of the bio_pair_release are in between the new lines of bio_split(). Please ??? This is a freaking important and capable exported function. Could you please put some comment on what it does and what are it's limitation. For example the returned bio is the beginning of the chain and the original is the reminder, right? Is this true also when &lt; at &gt;bio is not from &lt; at &gt;bs ? Is it at all supported when they are not the same? Are kmalloc bios not split-able? Please put answer to these in above comment. In the split you have a single bio with or without bvects allocation should you not let the caller make sure not to set __GFP_WAIT. For me, inspecting current-&gt;bio_list is out of context and a complete hack. The caller should take care of it, which has more context. For exa</pre> Boaz Harrosh 2012-05-24T16:56:03 http://permalink.gmane.org/gmane.linux.file-systems/64617 <pre> Which consolidations are happening and which drivers are being affected how? Why is this safe? If it's only bioset related API changes, why are there other changes at all? If the new clone interface can handle bioset fine, do we still need to expose __bio_clone()? Why is idx != bi_idx test dropped? I'm gonna stop here on this series. It doesn't seem like the issues pointed out before have been addressed. I recommend spending more effort on patch descriptions. Writing descriptions is not only important for reviewing and history but it's a good step in ensuring the patches are sane and properly split. If you can't explain each change in the patch, it generally means either the changes themselves are wrong or wrongly split. Thanks. </pre> Tejun Heo 2012-05-24T16:38:31 http://permalink.gmane.org/gmane.linux.file-systems/64613 <pre> I'd also recommend changing the "ok" and "common" labels in do_last() to something a bit more meaningful, perhaps: common -&gt; finish_open ok -&gt; finish_open_may_want_write Also, does it make sense to combine: if (!S_ISREG(nd-&gt;inode-&gt;i_mode)) will_truncate = 0; with: int will_truncate = open_flag &amp; O_TRUNC; up at the top of the function. As the code stands, if -&gt;atomic_open() opens the file but does not create it, handle_truncate() will be called on it even if it is not a regular file, whereas by the normal path, it won't. I would also be tempted to move the body of: if (filp == ERR_PTR(-EOPENSTALE) &amp;&amp; save_parent.dentry &amp;&amp; !retried) { BUG_ON(save_parent.dentry != dir); path_put(&amp;nd-&gt;path); nd-&gt;path = save_parent; nd-&gt;inode = dir-&gt;d_inode; save_parent.mnt = NULL; save_parent.dentry = NULL; if (want_write) { mnt_drop_write(nd-&gt;path.mnt); want_write = 0; } retried = true; goto retry_lookup; } before the retry_lookup label and then goto around it from the preceding if-e</pre> David Howells 2012-05-24T15:52:02 http://permalink.gmane.org/gmane.linux.file-systems/64612 <pre> I've been looking at your patches when they're all applied, and I suspect you're missing some security calls. For instance, in lookup_open(), you call security_path_mknod() prior to calling vfs_create(), but you don't call it prior to calling atomic_open() or in, say, nfs_atomic_open(). You do need to, however, though I can see it's difficult to work out where. Is it possible to call it if O_CREAT is specified and d_inode is NULL right before calling atomic_open()? I'm also wondering if you're missing an audit_inode() call in the if (created) path after the retry_lookup label. David -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> David Howells 2012-05-24T15:07:26 http://permalink.gmane.org/gmane.linux.file-systems/64611 <pre> Personally I had it with scsi-lib's sg_table bigger than PAGE_SIZE allocation. (Because of a bug) It is currently MAXed at PAGE_SIZE. Other people reported same failures and great performance degradation when allocating BIOs and BIO_VECs larger then PAGE_SIZE. It's simply the old and known page-fragmentation problem. It's why virtual memory was invented in the first place. kmalloc is not a virtual allocator. Welcome to Linux Kernel 101. vmalloc is ten fold slower than kmalloc. And in principal the same will happen, multiple discrete pages will be allocated, and collected together but now you will need to set up a TLB entries, and make sure they are mapped in when needed. (Every interrupt every context switch) This single fact of "Linux Kernel code does not use VM" is a 10 fold speed gain over Windows Kernel, measured. Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org</pre> Boaz Harrosh 2012-05-24T14:05:42 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.file-systems