This patch fixes the following problem:
- If we failed to deal with the delayed dir items, we should abort transaction,
just as its comment said. Fix it.
- If root reference or root back reference insertion failed, we should
abort transaction. Fix it.
- Do not restore the trans->rsv if we doesn
The snapshot should be the image of the fs tree before it was created,
so the metadata of the snapshot should not exist in the its tree. But now, we
found the directory item and directory name index is in both the snapshot tree
and the fs tree. It introduces some problems and makes the users feel s
On Mon, 2012-07-30 at 23:26 -0400, serial...@lavabit.com wrote:
> Hi all, so I've filled out an awesome ID10T form this weekend (all
> starting with a forded update) and completely annialated my partitions...
> I was running btrfs and was wondering 2 things:
>
> 1) is there a tool to help me recov
> On Mon, 2012-07-30 at 23:26 -0400, serial...@lavabit.com wrote:
>> Hi all, so I've filled out an awesome ID10T form this weekend (all
>> starting with a forded update) and completely annialated my
>> partitions...
>> I was running btrfs and was wondering 2 things:
>>
>> 1) is there a tool to help
Hi Alexander,
I relooked at my list of questions, and it seems that there are more
general questions, and more focused questions. So here I list the
"more focused" ones. I really appreciate if you can address them. I
hope it's ok that I opened a separate thread for them. So here goes...
iterate_di
In check-integrity, detect when a superblock is written that points
to blocks that have not been written to disk due to I/O write errors.
Signed-off-by: Stefan Behrens
---
fs/btrfs/check-integrity.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/ch
With commit acce952b0, btrfs was changed to flag the filesystem with
BTRFS_SUPER_FLAG_ERROR and switch to read-only mode after a fatal
error happened like a write I/O errors of all mirrors.
In such situations, on unmount, the superblock is written in
btrfs_error_commit_super(). This is done with th
Hello everybody,
here is my revised patch free from checkpatch warnings and based on the right
git tree.
Alexander Karbstein (1):
Btrfs-progs: Enabled setting root subvolume with subvolid=0
cmds-subvolume.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
--
1.7.2.5
--
To unsu
The command btrfs subvolume set-default 0 /path/to/fs changed the
default subvolume to whatever subvolume was currently mounted on
/path/to/fs. This patch changes this behaviour to set the default
subvolume to BTRFS_FS_TREE_OBJECTID in case the user asks for
subvolid=0
Signed-off-by: Alexander Kar
Just realized I messed up sending this to the list.
Roman Mamedov wrote:
> On Mon, 30 Jul 2012 23:26:42 -0400 (EDT)
> serial...@lavabit.com wrote:
>
>> 1) is there a tool to help me recover data from my fs? I don't have a
>> backup of my partition table and so I have about 500GB of space where a
Alex Elsayed wrote:
> offset 0x10040 (64K + 64 bytes) there's the string BHRfS (hex 5F 42 48 52
> 66 53 5f). That matches the documentation (the first superblock should be
Ugh, and resending it stripped the underscores. _BHRfS_ is at 0x10040, not
BHRfS (which would be at 0x10041)
--
To unsubscri
In using btrfs-restore, I've found that much of the time the interface is a
poor match for what I'm trying to do. It works fine in the simplest cases
where you want to extract everything, but wanting to extract a subset of the
files in a directory is more difficult, and it gets more complicated
I've been working on running down intermittent ENOSPC issues.
I can only seem to replicate ENOSPC errors when running zlib
compression. However, I have been seeing similar ENOSPC errors to a
lesser extent when playing with the LZ4HC patches.
I apologize for not following up on this sooner, but I
A deadlock in xfstests 113 was uncovered by commit
d187663ef24cd3d033f0cbf2867e70b36a3a90b8
This is because we would not return EIOCBQUEUED for short AIO reads, instead
we'd wait for the DIO to complete and then return the amount of data we
transferred, which would allow our stuff to unlock the r
Hi Bo,
On 07/31/2012 07:49 AM, Liu Bo wrote:
> The idea is that we usually use snapshot to backup/restore our data, and the
> common way can be a cron script which makes lots of snapshots, so we can end
> up with spending some time to find the latest snapshot to restore.
>
> This adds a feature f
> +static void btrfs_direct_read_iodone(struct kiocb *iocb, loff_t offset,
> + ssize_t bytes, void *private, int ret,
> + bool is_async)
> +{
> + struct inode *inode = iocb->ki_filp->f_mapping->host;
> + u64 lockend;
> +
> +
On Tue, Jul 31, 2012 at 11:04:12AM -0700, Marc MERLIN wrote:
> My kernel crashed for some other reason, and now I can't mount my btrfs
> filesystem.
> I don't care about the data, it's backed up.
>
> I'll compile a 3.5 kernel, but is there any info you'd like off that
> filesystem to see why btrfs
> [ 186.277795] Btrfs detected SSD devices, enabling SSD mode
> [ 188.477443] btrfs: unlinked 6 orphans
> [ 188.477451] btrfs: truncated 1 orphans
> [ 411.837015] btrfs: unlinked 13 orphans
> [ 414.373500] btrfs: unlinked 35 orphans
>
> This seems to hint that I lost random files and that I do
With Chris's current for-linus branch against 3.5.0, while doing I/O
and defrag/balance/scrub for a short time, I see btrfs_search_slot
fail to find the key, leaving it's loop and returning one, tripping
this assertion [1].
Let me know if interested for more testing/details/debug.
Thanks,
Danie
On Fri, Jul 27, 2012 at 11:42:39AM -0700, Marc MERLIN wrote:
> > https://oss.oracle.com/~mason/latencytop.patch
>
> Thanks for the patch, and yes I can confirm I'm definitely not pegged on CPU
> (not even close and I get the same problem with unencrypted filesystem,
> actually
> du -sh is exactl
On Wed, Aug 1, 2012 at 1:01 PM, Marc MERLIN wrote:
> So, clearly, there is something wrong with the samsung 830 SSD with linux
> It it were a random crappy SSD from a random vendor, I'd blame the SSD, but
> I have a hard time believing that samsung is selling SSDs that are slower
> than hard dr
On Wed, Aug 01, 2012 at 01:08:46PM +0700, Fajar A. Nugraha wrote:
> > It it were a random crappy SSD from a random vendor, I'd blame the SSD, but
> > I have a hard time believing that samsung is selling SSDs that are slower
> > than hard drives at random IO and 'seeks'.
>
> You'd be surprised on h
On 01/08/12 16:01, Marc MERLIN wrote:
> Third, A freshly made ntfs filesystem through fuse is actually FASTER!
Could it be that Samsungs FTL has optimisations in it for NTFS ?
A horrible thought, but not impossible..
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
--
To unsubsc
On Wed, Aug 01, 2012 at 04:36:22PM +1000, Chris Samuel wrote:
> On 01/08/12 16:01, Marc MERLIN wrote:
>
> > Third, A freshly made ntfs filesystem through fuse is actually FASTER!
>
> Could it be that Samsungs FTL has optimisations in it for NTFS ?
>
> A horrible thought, but not impossible..
No
24 matches
Mail list logo
