As far as I know TRIM was enabled. I didn't forcibly disable it and I'm under
the assumption that btrfs enables it when an SSD is detected.
-- Original Message --
From: Chris Mason
To: Justin
Cc: linux-btrfs@vger.kernel.org
Subject: Re: btrfs Bug?
Date: Fri, 9 Apr 2010 07:18:44
On Friday 09 April 2010, Harshavardhana wrote:
> On 04/09/2010 02:07 PM, Harshavardhana wrote:
> > EBUSY is again meant for different reason where in a super block is
> > being locked or accessed by an Application which would mean unref on
> > that block would cause Application to go nuts. In suc
Hi,
while running some filesystem benchmarks[0] I noticed the following
message in my logs during bonnie++:
device fsid 944150ad12159fd6-cc6b5d7368bfb90 devid 1 transid 7 /dev/md0
INFO: task btrfs-transacti:4083 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs
On 04/09/2010 02:07 PM, Harshavardhana wrote:
EBUSY is again meant for different reason where in a super block is
being locked or accessed by an Application which would mean unref on
that block would cause Application to go nuts. In such cases EBUSY is
returned.
Ok i think ENOTSUPP could be an
On 04/09/2010 11:54 AM, Goffredo Baroncelli wrote:
EBUSY (not on Linux)
The file pathname cannot be unlinked because it is being used by
the system or another process and the implementation considers
this an error.
[...]
EPERM The s
Ok,
I read the unlink (2) man page which says:
[...]
EBUSY (not on Linux)
The file pathname cannot be unlinked because it is being used by
the system or another process and the implementation considers
this an error.
[...]
EPERM The syst
On 04/09/2010 10:58 AM, Goffredo Baroncelli wrote:
Can I suggest to return -EINVAL instead of -EPERM ?
To me EPERM seems that the user don't have the right to perform an action. But
the problem is that "rm" is not the right command to use in order to delete a
subvolume.
As side note, what is the
The latest unstable git pull fixed a little problem I had with rm -r.
With a filled up filesystem, rm -rwould stop after a few minutes say
"filesystem full', but a subsequent rm -r would clear the filesystem.
Now, it acts as it should, and removed all the files and directories
the first time.
--
Hi all,
Can I suggest to return -EINVAL instead of -EPERM ?
To me EPERM seems that the user don't have the right to perform an action. But
the problem is that "rm" is not the right command to use in order to delete a
subvolume.
As side note, what is the reason for which an user is able to creat
On Thu, Apr 08, 2010 at 06:46:40PM +, Justin wrote:
> Unfortunately I did reformat.
> Actually, I did a complete zero-out of the drive with dd, and then I ran
> "badblocks -w" on the drive, which returned 0 bad blocks (not sure if this is
> really a good test for SSD's as there's some amount
10 matches
Mail list logo
