On 23/01/12 4:01 AM, Bruno Wolff III wrote:
> On Mon, Jan 23, 2012 at 00:31:38 -0600,
> Bruno Wolff III wrote:
>> On Sun, Jan 22, 2012 at 20:52:43 -0430,
>> Patrick O'Callaghan wrote:
>>>
>>> Apparently kernel 3.3 will have a fix for this problem, but that's
>>> expected to be around the end
On Mon, Jan 23, 2012 at 00:31:38 -0600,
Bruno Wolff III wrote:
> On Sun, Jan 22, 2012 at 20:52:43 -0430,
> Patrick O'Callaghan wrote:
> >
> > Apparently kernel 3.3 will have a fix for this problem, but that's
> > expected to be around the end of March unless someone backports it.
>
> 3.3 rc
On Sun, Jan 22, 2012 at 20:52:43 -0430,
Patrick O'Callaghan wrote:
>
> Apparently kernel 3.3 will have a fix for this problem, but that's
> expected to be around the end of March unless someone backports it.
3.3 rc1 has been built for rawhide and should work on f16 if you want to
try it now.
-
On Sun, 2012-01-22 at 23:00 -0430, Patrick O'Callaghan wrote:
> On Mon, 2012-01-23 at 02:41 +, Marko Vojinovic wrote:
> > I have chosen to set up the "madvise" state rather than the "never"
> > state, so
> > I added "transparent_hugepage=madvise" to the GRUB_CMDLINE_LINUX line
> > in
> > /etc
On Mon, 2012-01-23 at 03:25 +, Marko Vojinovic wrote:
> On Monday 23 January 2012 02:41:07 you wrote:
> > Now I'll see how USB is going to work --- a 2.2 GB file is about to be
> > written... ;-)
>
> As a side note --- is it normal to have the write-to-USB-flash speed of
> 2.5 MiB/s (on averag
On Mon, 2012-01-23 at 02:41 +, Marko Vojinovic wrote:
> I have chosen to set up the "madvise" state rather than the "never"
> state, so
> I added "transparent_hugepage=madvise" to the GRUB_CMDLINE_LINUX line
> in
> /etc/default/grub, ran "grub2-mkconfig /boot/grub2/grub.cfg" to
> activate the
On Monday 23 January 2012 02:41:07 you wrote:
> Now I'll see how USB is going to work --- a 2.2 GB file is about to be
> written... ;-)
As a side note --- is it normal to have the write-to-USB-flash speed of
2.5 MiB/s (on average)?
I am supposedly using USB2.0 port, and have a 8 GB flash drive. W
On Sunday 22 January 2012 20:52:43 Patrick O'Callaghan wrote:
> On Sat, 2012-01-21 at 14:05 -0430, Patrick O'Callaghan wrote:
> > This was really bothering me (I make frequent use of pendrives) so took
> > another look at the above article, then
> > at /usr/share/doc/kernel-doc-3.1.9/Documentation/
On Sat, 2012-01-21 at 14:05 -0430, Patrick O'Callaghan wrote:
> On Sat, 2011-12-17 at 21:17 -0430, Patrick O'Callaghan wrote:
> > On Sun, 2011-12-18 at 01:37 +, Marko Vojinovic wrote:
> > > On Saturday 17 December 2011 19:41:38 Patrick O'Callaghan wrote:
> > > > This looks like a regression. Un
On Sat, 2011-12-17 at 21:17 -0430, Patrick O'Callaghan wrote:
> On Sun, 2011-12-18 at 01:37 +, Marko Vojinovic wrote:
> > On Saturday 17 December 2011 19:41:38 Patrick O'Callaghan wrote:
> > > This looks like a regression. Under F15 when I wrote large files to a
> > > pendrive, the system would
On Thu, 2012-01-05 at 03:39 +0100, Reindl Harald wrote:
>
> Am 05.01.2012 03:02, schrieb Fernando Cassia:
> > On Sun, Dec 18, 2011 at 10:01, Patrick O'Callaghan
> > wrote:
> >> Understanding how the file abstraction works is to my mind a question of
> >> basic culture around here. As a piece of e
Am 05.01.2012 03:02, schrieb Fernando Cassia:
> On Sun, Dec 18, 2011 at 10:01, Patrick O'Callaghan
> wrote:
>> Understanding how the file abstraction works is to my mind a question of
>> basic culture around here. As a piece of engineering design balancing
>> functional elegance with practicalit
On Sun, Dec 18, 2011 at 09:01, Tim wrote:
> You probably want to research into "sparse files."
Thanks Tim,
One learns something every day. I had read about sparse files but
never used them, since I come from an IBM 32-bit OS/2 (HPFS)
background which I used for almost a full decade (1992-2002) a
On Sun, Dec 18, 2011 at 10:01, Patrick O'Callaghan
wrote:
> Understanding how the file abstraction works is to my mind a question of
> basic culture around here. As a piece of engineering design balancing
> functional elegance with practicality it's a wonderful thing to
> contemplate and a key ele
On 12/18/2011 11:56 AM, Patrick O'Callaghan wrote:
Nevertheless it happens and appears to affect other people as well.
Which makes it a subtle bug to find, unfortunately.
The OP should open a BZ report, with as much hardware detail as possible
and post a link here. Then, you can add a comment
On 12/18/2011 11:54 AM, Patrick O'Callaghan wrote:
I taught Unix filesystem fundamentals for years and I have no idea what
you're getting at. Just saying. If you want to be more specific perhaps
we can talk.
The link I gave has a rather simplistic explanation. I used to have a
link to a more
On Sun, 2011-12-18 at 19:55 +0100, Heinz Diehl wrote:
> On 18.12.2011, Patrick O'Callaghan wrote:
>
> > This looks like a regression. Under F15 when I wrote large files to a
> > pendrive, the system would become a little sluggish. Now it essentially
> > freezes until the write terminates. What I
On Sun, 2011-12-18 at 10:45 -0800, Joe Zeff wrote:
> On 12/18/2011 01:17 AM, Fernando Cassia wrote:
> > Is that what you are saying?.
>
> Did you follow the link I gave? It's what the explanation there
> implies. However, I'm guessing that the system only knows how big your
> first write is, n
On 18.12.2011, Patrick O'Callaghan wrote:
> This looks like a regression. Under F15 when I wrote large files to a
> pendrive, the system would become a little sluggish. Now it essentially
> freezes until the write terminates. What I mean is that the UI is almost
> completely unresponsive; even cl
On 12/18/2011 01:17 AM, Fernando Cassia wrote:
Is that what you are saying?.
Did you follow the link I gave? It's what the explanation there
implies. However, I'm guessing that the system only knows how big your
first write is, not how big the file's going to get, partially because
the pro
> > Actually, the fact that Linux drives don't need regular defragging has
> > nothing to do with the file system.
>
> Actually the fact that linux drives don't get defragged is more
> because there are no defragging tools than because there wouldn't
> be a performance benefit to having the secto
> the low-level APIs involved with file creation. Is there a way to tell
> the file system that you´re creating a file with total size "x" before
> any such data is written to it, I mean, as part of the file creation
> call?.
Yes.
> I mean, it is one thing to create a file with size 0, then start
On Sun, 2011-12-18 at 06:17 -0300, Fernando Cassia wrote:
> On Sun, Dec 18, 2011 at 04:14, Joe Zeff wrote:
> > Basically, the system tries to find a place big enough to hold the entire
> > file instead of putting the first chunk into the first place it finds.
>
> Please confirm if I understood th
On Sat, 2011-12-17 at 21:15 -0800, sourcerer_...@riseup.net wrote:
> > Actually, the fact that Linux drives don't need regular defragging has
> > nothing to do with the file system.
> It should still be possible to fragment a large file if, for example, you
> opened a file that covered more than 3
On Sun, 2011-12-18 at 06:17 -0300, Fernando Cassia wrote:
> I do know that for instance some bittorrent clients (Vuze -formerly
> azureus comes to mind) allocate the full size of the file being
> retrieved, then starts populating (writing) segments as those are
> downloaded, but I never knew if the
On Sun, Dec 18, 2011 at 04:14, Joe Zeff wrote:
> Basically, the system tries to find a place big enough to hold the entire
> file instead of putting the first chunk into the first place it finds.
Please confirm if I understood this right, as I¨m not familiar with
the low-level APIs involved with
On 12/17/2011 09:15 PM, sourcerer_...@riseup.net wrote:
Well, what is that reason?
The link I gave has an explanation. Basically, the system tries to find
a place big enough to hold the entire file instead of putting the first
chunk into the first place it finds. And, as it spreads files ou
> Actually, the fact that Linux drives don't need regular defragging has
> nothing to do with the file system.
Well, what is that reason? I know that ext4 offers 'extents' and that
reduces fragmentation, but I don't see any other reason why the ext*
family of filesystems are more immune to fragmen
On Sat, 2011-12-17 at 22:01 -0500, Tom Horsley wrote:
> On Sat, 17 Dec 2011 18:49:48 -0800
> Joe Zeff wrote:
>
> > Actually, the fact that Linux drives don't need regular defragging has
> > nothing to do with the file system.
>
> Actually the fact that linux drives don't get defragged is more
>
On Sat, 17 Dec 2011 18:49:48 -0800
Joe Zeff wrote:
> Actually, the fact that Linux drives don't need regular defragging has
> nothing to do with the file system.
Actually the fact that linux drives don't get defragged is more
because there are no defragging tools than because there wouldn't
be a
On 12/17/2011 06:35 PM, Marko Vojinovic wrote:
We Linux users usually make fun of Windows users for having to defragment
their hard drives every now and then, while our ext2/3/4 solution is sooo far
superior.
Actually, the fact that Linux drives don't need regular defragging has
nothing to do
On Saturday 17 December 2011 21:17:19 Patrick O'Callaghan wrote:
> On Sun, 2011-12-18 at 01:37 +, Marko Vojinovic wrote:
> > On Saturday 17 December 2011 19:41:38 Patrick O'Callaghan wrote:
> > > This looks like a regression. Under F15 when I wrote large files to
> > > a
> > > pendrive, the sys
On Sun, 2011-12-18 at 01:37 +, Marko Vojinovic wrote:
> On Saturday 17 December 2011 19:41:38 Patrick O'Callaghan wrote:
> > This looks like a regression. Under F15 when I wrote large files to a
> > pendrive, the system would become a little sluggish. Now it essentially
> > freezes until the wr
On Saturday 17 December 2011 19:41:38 Patrick O'Callaghan wrote:
> This looks like a regression. Under F15 when I wrote large files to a
> pendrive, the system would become a little sluggish. Now it essentially
> freezes until the write terminates. What I mean is that the UI is almost
> completely
This looks like a regression. Under F15 when I wrote large files to a
pendrive, the system would become a little sluggish. Now it essentially
freezes until the write terminates. What I mean is that the UI is almost
completely unresponsive; even clicking between two terminal windows is
so slow that
35 matches
Mail list logo
